[PATCH] VTY enable then write crashed gproxy; this patch fixes it.

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/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Sun Mar 3 12:50:27 UTC 2013


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 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 OpenBSC mailing list