Hi Katerina,
On Sun, Mar 03, 2013 at 07:15:24AM +0000, Katerina Barone-Adesi wrote:
The previous code made gprs_categories have 18
entries,
rather than the 3 a glance would suggest. The first 15 were all-0,
as per implicit initialization of static objects in the c standard.
This caused problems for code in libosmocore which expected actual data.
There are three potential solutions:
a) Define a new enum for gprs_categories
b) Change libosmocore to not crash on all-zero input categories.
c) Simply use log_info, which has a superset of the information.
This patch implements c, the simplest.
sgsn_main.c had a similar problem; it implicitly had 20 categories.
(see readelf -s gprs/osmo-sgsn | grep gprs_categories).
I was aware of the problem, but never found time for a proper solution.
In general, I prefer to have one enum and not program-specific enums, as
we tend to move code from one executable to another over tiem and I
would like to avoid clashes.
The probelm with the current attempt of registering the full log_info is
that if you type "logging level <tab>" in the SGSN, it will show you a
long list of categories that make absolutely no sense in the context of
the SGSN. There is no call control, rsl or lapdm in the context of
GPRS.
One idea might be to have another member of the struct that allows them
to be globally disabled/invisible. This way the SGSN startup code could
specify which log categories are actually used, and the VTY strings
would be generated only for that sub-set of categories.
I'm open for other ideas, too...
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)