Cellular Network Infrastructure

IMO we should not use numbers like X23001 but start with lower numbers.
We could think of either creating a number space for each program, like osmo-bts has X1000-X1999, osmo-bsc X2000-X2999 etc.,
or just start with X1 and assign the next X2, X3 etc, whichever comes along next, like we did in Port_Numbers.

Thanks for creating the issue!

neels wrote:

IMO we should not use numbers like X23001 but start with lower numbers.
We could think of either creating a number space for each program, like osmo-bts has X1000-X1999, osmo-bsc X2000-X2999 etc.,
or just start with X1 and assign the next X2, X3 etc, whichever comes along next, like we did in Port_Numbers.

I'd prefer the number space, so it's clear to which program a timer belongs.

Do we need more opinions on this (laforge, fixeria, pespin?), or can I create such a wiki page and start using these numbers in my open related osmo-bsc patch?

Do we need more opinions on this (laforge, fixeria, pespin?)

I definitely like the idea of having unique 'X' timer numbers. But still, it's unclean to me how do we ensure backwards compatibility, i.e. what should we do with the existing timer numbers that are used in more than one project (e.g. X1)?

can I create such a wiki page and start using these numbers in my open related osmo-bsc patch?

It probably makes sense to have a header file in libosmocore listing all used timers, so then we could automatically generate the wiki page from it. This way it's less likely that somebody forgets to reserve a port number, and somebody else starts to use it in another osmo-* program.

I'm fine with having a unique list in a wiki page listing all X timers.

Regarding starting timers from X1 and so: I don't think it's generally a good idea (though it can be for some cases). What I mean is: Sometimes afair some of our X timers are highly related to a standard timer T, in which cases it makes sense to keep either Xn for Tn, or some value around n, specially since sometimes in standard some related timers have similar numbering.

I've been pondering the thought of fixing X timer numbers.
It is easiest to just change the number, hence the config changes and probably fails, saying "timer X23 does not exist" all of a sudden.
But ideally, when we change a timer number, we would keep some backwards compatibility in the configuration.
We are currently missing any approach to provide backwards compat for old timer numbers.
Most (new) timers are managed by tdef_vty.h which makes no provision for backwards compat.
It might be possible to implement separate vty functions, without the need for a generic approach, like:

DEFUN(deprecated_timers, deprecated_timers_cmd,
      "timer (T23|T42|X99) .IGNORED")
{
   vty_out("Timer numbers have changed, please adjust your config: T23->X17 T42->X18 X99->X19");
   return CMD_WARNING;
 }

could possibly be advanced to actually redirecting the legacy number to a new proper number, maybe like:

DEFUN(deprecated_timer_T23, deprecated_timer_T23_cmd,
      "timer T23 .ARGS")
{
   vty_out("Timer T23 is now X17, please adjust your config");
   argv[0] = "X17"; // somehow something like this
   return cfg_timer_cmd(vty, argc, argv);  // meaning the tdef_vty.c cfg_timer_cmd
 }

After https://gerrit.osmocom.org/c/osmo-bsc/+/17973 was assigned to me, I figured now is as good a time as ever to clean up the timers.

I collected all osmo_tdef timers I could find in:
https://osmocom.org/projects/cellular-infrastructure/wiki/List_of_Timer_numbers
(the wiki page reflects the status after merging pending patches https://gerrit.osmocom.org/q/topic:%22timers%22+(status:open%20OR%20status:merged) )

From that it became apparent that only OsmoBSC exposes T timers that are not specified by 3GPP.
Adding timer groups to OsmoBSC like in OsmoMSC (backwards compatibly) was a nice fit to move those to X timers.
https://gerrit.osmocom.org/c/osmo-bsc/+/20155

Also fixed an mgw timer in osmo-msc https://gerrit.osmocom.org/c/osmo-msc/+/20156

wait for merge of course