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@gnumonks.org https://laforge.gnumonks.org/

============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi,

On 17.07.23 08:49, Harald Welte wrote:

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

Created this issue to follow up: https://osmocom.org/issues/6122

Best regards, Oliver