osmocom-net-gprs July 2023

osmocom-net-gprs@lists.osmocom.org

6 participants
3 discussions

Osmocom discourse as alternative to mailing lists
by Harald Welte 27 Jul '23

27 Jul '23

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)

1 0

[PATCH net-next 0/3] net: Remove more RTO_ONLINK users.
by Guillaume Nault 19 Jul '23

19 Jul '23

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

2 2

Deprecating support for big endian in Osmocom
by Harald Welte 17 Jul '23

17 Jul '23

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)

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs July 2023