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
Hi Harald,
On 27/06/11 11:00, Harald Welte wrote:
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.
Since I required something for libosmo-abis I prepared the following patch. The idea is to reduce the logging range to uint8_t:
* we reserve logging subsystems space for libraries. * It allows to dinamically register as many logging subsystems as you want, by invoking log_init(...) as many times as needed.
This breaks binary backward compatibility.
-
Harald Welte -
Pablo Neira Ayuso