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
- 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)