Attention is currently required from: jolly, laforge, pespin.
1 comment:
File include/osmocom/core/logging.h:
Patch Set #2, Line 158: #defin
However, still the API is being changed due to modification of OSMO_NUM_DLIB.
Well, `OSMO_NUM_DLIB` is a special value reflecting the total number of those global l-categories. It would be weird if anyone expected this value to remain constant, and even more weird if it's used anywhere else than in libosmocore.git.
Same applies to `_NUM_OSMO_ECU_CODECS`, `_OSMO_AUTH_ALG_NUM`, `_NUM_BTS_FEAT`, for instance: their existence does not imply that new elements shall not be added.
In this specific case we could even remove it completely and let the compiler calculate the size of `internal_cat[]` at compile-time for us.
it makes much more sense that each library dynamically defines its own set of log categories which can be configured through API,
I don't have a strong opinion here. To me it's just another approach, without `makes much more sense` or `totally correct`. It works for `libosmo-gprs` libs because so far only one project using it (`osmo-{pcu,sgsn}` may also join this list later). But it's inconvenient when multiple projects depend on a library and have to define the same set of logging categories for it. This is likely the case for `libosmo-cc`: `osmo-msc`, `osmocom-bb` [potentially], and 6 more repositories in https://gitea.osmocom.org/cc.
So, all in all, I see nothing really special about this API change and would go for having a global l-logging category here once (what this patch does), rather than having duplicate definitions in each of those 6+ projects.
To view, visit change 35572. To unsubscribe, or for help writing mail filters, visit settings.