TLDR; I lean towards dropping BE support.
From my personal, practical POV, I have no need ever of using a BE platform.
It's true that running the struct_endianness.py is not much effort, but that
script is not very intelligent and can only handle very specific cases (IIRC
unions don't work, and the data type needs to be <= 8bit). I remember that
recently there was a case of that script not working properly. So there is at
leat *some* quirkiness that remains, even though we have this script.
So my first thought is: yes, let's just drop this ugly stuff that clutters our
source code, may complicate how we lay out our structs, and that literally
no-one is using anywhere. Simplify, simplify.
Another thought is that a good friend of mine likes to operate legacy hardware,
and there I've often heard complaints that some upstream X just completely
dropped perfectly good support for hardware Y because they falsely assumed
no-one is using it. Now I'm not so sure if that friend of mine is literally the
only person complaining about it, or if it is a bad thing in general? That
would be my only point for keeping big endian support.
My final thought is that I wonder how other projects handle this. Every C/C++
code is having this problem. I find it curious that the endianness of packed
structs is not abstracted away by the *compiler*, where it probably should be?
BTW, TIL where the term Endian originated -- despite it seeming so obvious in
hindsight -- and if you don't know yet:
https://en.wikipedia.org/wiki/Endianness#Etymology
"The adjective endian has its origin in the writings of 18th century
Anglo-Irish writer Jonathan Swift. In the 1726 novel Gulliver's Travels, he
portrays the conflict between sects of Lilliputians divided into those breaking
the shell of a boiled egg from the big end or from the little end..."
~N
On Mon, Jul 17, 2023 at 08:49:02AM +0200, Harald Welte wrote:
Hi all,
during recent patch review
(
https://gerrit.osmocom.org/c/osmo-trx/+/33737) the topic of continuing
to maintain support for big endian machines has come up.
While traditionally I've always been a strong proponent of writing
portable code that can run also on big endian systems, it is not the
year 2003 or 2008 anymore, and PowerPC (the main big endian platform) is
dead by now, as is SPARC. Not just in newly-built processors, but also
in existing and still operating machines, at least of the class that
would run our code.
So unless somebody objects with strong arguments, I'd propose to
officially and explicitly drop supporting big endian systems from
osmocom CNI projects.
From what I can tell, this would primarily mean
* drop the struct_endianness check from the commit verification
* removing all our struct_endianness-generated or other code that
explicitly adds big endian support
* adding some kind of #warning or even #error to a common libosmocore
header file if anyone tries to build on big endian
This obviously doesn't mean we can abandon using [osmo_]{htonl,ntohl},
as network byte order is still network byte order.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte