Attention is currently required from: fixeria, jolly, laforge, pespin. falconia has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email ) Change subject: bring twjit into libosmo-netif ...................................................................... Patch Set 6: (2 comments) File include/osmocom/netif/twjit.h: https://gerrit.osmocom.org/c/libosmo-netif/+/39280/comment/8c1d16d9_56ae42d… : PS6, Line 50: struct osmo_twjit_config { The only struct that poses truly serious ABI issues is `osmo_twjit_config`. In ThemWi applications using `twrtp-native`, and also in my on-branches OsmoBTS patches prior to you raising this issue just now, the twjit config struct is embedded directly into some application data structure. This arrangement is not a problem with `twrtp-native` as the latter is a static lib, but I see now how it would be a problem in Osmocom-integrated version. If an application is compiled against one version of `libosmo-netif` and its header files, and then the shared lib is replaced with a newer version in which twjit config struct gained extra fields, breakage will ensue: created/configured twjit instances will read garbage in the new fields, while vty code in the library will write past the end of the application-provided struct. The only solution I can think of is to replace `osmo_twjit_config_init()` with `osmo_twjit_config_create()` or `osmo_twjit_config_alloc()` (please indicate which naming you prefer), make this config struct fully opaque, and implement setter functions for those rare apps that might need to control these settings through non-vty means. However, in the case of `osmo_twjit_stats`, `osmo_twjit_rr_info` and `osmo_twrtp_stats` addressed in the other patch, I argue we can go for a simpler approach. All of these structures are only allocated by the library inside opaque twjit and twrtp instance structs, while library users get only const pointers to them. Therefore, ABI breakage can be avoided by adopting a policy inside the library (documented with inline comments) that these structs can be extended only by adding new fields at the end. Already defined fields cannot be dropped - just the API alone imposes this requirement, before considering ABI - but for ABI reasons, they cannot be reordered either. I shall wait for your feedback before I implement this proposed solution. File src/twjit.c: https://gerrit.osmocom.org/c/libosmo-netif/+/39280/comment/ed40f9f1_cf27b2f… : PS2, Line 504: rtph = osmo_rtp_get_hdr(msg); Can this issue be marked as resolved - is M bit handled to your satisfaction now? -- To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-netif Gerrit-Branch: master Gerrit-Change-Id: Ia3be5834571ca18b68939abbcf1ce3a879156658 Gerrit-Change-Number: 39280 Gerrit-PatchSet: 6 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: jolly <andreas(a)eversberg.eu> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: jolly <andreas(a)eversberg.eu> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Mon, 25 Aug 2025 17:06:44 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: falconia <falcon(a)freecalypso.org> Comment-In-Reply-To: laforge <laforge(a)osmocom.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>