This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi! As more and more code is moving into libraries (like I just did with the LAPDm code, and like pablo is working on with libosmo-abis), we needed a solution how to allocate and use the LOGP subsystem constants like DRSL, DRR, ... from within libraries. The existing logging code wasn't really prepared for that. I've now come um with a hack to extend it while preserving compatibility to applications: * we use negative numbers starting from -1 for library-internal subsystems * those numbers get converted to a positive index into the various arrays at run-time. So -1 ends up one entry higher in the array than the last application-providede log category/subsystem. As part of this change, the array allocations are now dynamic, i.e there is no maximum limit for the number of log categories that an application can register with the core. Only for libraries (even outside libosmocore), we have compile-time registration, i.e. the 'struct log_info_cat' and the D* constant need to be defined inside libosmocore. I think this is an acceptable compromise. Furthermore, if LOGP()/DEBUGP() ever see a subsystem number that it doesn't know, it will assign it to the new 'DLGLOBAL' (Debug Library GLOBAL) category, i.e. there cna be no array overflows. This ensures that even an external library using a 'newer' D* constant will not crash or otherwise fail, it will simply log in a slightly different way. Regards, Harald -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)