Dear Osmocom community,
while many people with a long history in FOSS development have no issues
at all with mailing lists as primary form of engaging with their
community, they have undoubtedly fallen out of fashion in favor of
various chat/messaging systems or web based forums.
In Osmocom, we've just launched an installation of the discourse forum
software available at https://discourse.osmocom.org/ providing an
alternative to our traditional mailing lists at https://lists.osmocom.org/
We're looking forward to see whether this web-based approach will
facilitate more and/or other people to engage with the Osmocom
developer/contributor community.
Feel free to join and get the discussions started. If there's a need
for more categories or sub-categories, just let one of the moderators
know and we can help with that.
The old mailing lists will continue to remain available for those who
prefer them.
--
- Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Code that initialise a flowi4 structure manually before doing a fib
lookup can easily avoid overloading ->flowi4_tos with the RTO_ONLINK
bit. They can just set ->flowi4_scope correctly instead.
Properly separating the routing scope from ->flowi4_tos will allow to
eventually convert this field to dscp_t (to ensure proper separation
between DSCP and ECN).
Guillaume Nault (3):
gtp: Set TOS and routing scope independently for fib lookups.
dccp: Set TOS and routing scope independently for fib lookups.
sctp: Set TOS and routing scope independently for fib lookups.
drivers/net/gtp.c | 3 ++-
net/dccp/ipv4.c | 3 ++-
net/sctp/protocol.c | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
--
2.39.2
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)
