Hi Neels and others,
On Mon, Jul 17, 2023 at 07:58:31PM +0200, Neels Hofmeyr wrote:
From my personal, practical POV, I have no need ever of using a BE platform.
For me its different: I have been using BE in the past and I may still use BE platforms at some point in time. But that's my personal retrocomputing intrest, and I don't need to run osmo* on it. And if I want, it is my personal choice to invest time into it, I don't want to burden other developers with it.
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.
yes, we have that script, it doesn't handle all cases, and we have zero testing.
So rather than providing the impression we have BE support, let's just drop it and be clear about it. If anyone actually shows up and wants to maintain it, we wouldn't mind related patches, I guess. Similar to the statement at the time we dropped FreeBSD support: If somebody wants to work on that and provide alternatives for the various linux-specific bits in libosmocore (timerfd, etc.) - fine.
Another thought is that a good friend of mine likes to operate legacy hardware, [...]
I am such a person myself, see above. But it is not the job of the average osmocom developer to care for the peculiar fetishes of 0.0001% of a user base that's already working in a niche industry.
Every C/C++ code is having this problem.
Well, every C/C++ code dealing with external binary data formats stored in a non-native endianess. So pure application code dealing only with textual protocols (HTTP, SMTP, ...) or data formats (XML, JSON) is unaffected.