libosmocore / logging from within libraries

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.org
Mon Jun 27 09:00:37 UTC 2011


Hi!

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)




More information about the baseband-devel mailing list