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 <[email protected]> https://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) -- - Neels Hofmeyr <[email protected]> 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
