RFC extend osmo_signal infrastructure

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/.

Daniel Willmann daniel at totalueberwachung.de
Fri Oct 7 13:58:13 UTC 2011


Hello list,

I would like to be able to send a TRAP over the control interface
for certain signals. For this it would be nice if the signals have a
text representation of their name as is the case with the (rate)
counters.

I want to propose a different API where you register the signals (and
maybe even the subsystems) and provide a name for them.

The function register_signal would then return the numeric
representation of the signal. The performance hit would only be during
registering, not during dispatch.

The callback function would still be called with the numeric
representation in order to avoid resolving the name to the number every
time.

Inside the callback you would have to resolve the name of the signal to
the actual number, but using static variables you'll only have to do it
the first time:

void signal_cb(unsigned int subsysnum, unsigned int signalnum,
		void *signal_data, void *handler_data)
{
	static unsigned int foosig, barsig;

	if (foosig == 0) {
		foosig = osmo_signal_get_by_name("foo");
	}
	if (barsig == 0) {
		barsig = osmo_signal_get_by_name("bar");
	}
	
	switch (signalnum) {
	case foosig:
		do_stuff;
		break;
	case barsig:
		do_other_stuff;
		break;
	}
}

The functions that dispatch the signals would have to do something
similar.

Ideas? Is this too complex?
Do we gain enough from registering signals at runtime or should we
rather keep the enums and add a value_string for the name/description?


Regards,
Daniel Willmann




More information about the OpenBSC mailing list