I have a libosmocore patch that verifies the validity of counter names
(to not contain spaces or dots) at registration time. This way we can
catch any application with erroneous behaviour.
However, this causes the following problem: New libosmocore versions
will make old apps crash or at least fail to have propre counters, as
their names are wrong :(
Also, I don't like to replace all '.' in the counter with '_', as in
seen in the example of 'bssgp.bss_ctx' there is a semantic difference.
'bssgp.' is denoted to indicate the code module from which the counter
is, and 'bss_ctx' denotes the specific object whose counters we refer
to. Manually replacing this with 'bssgp_bss_ctx' is ugly.
One alternative would be to replace '.' with ':' or '/', which are not
characters with a special functoin in the CTRL syntax. This could be
even done automatically at counter registration time, simply replace all
occurrences of '.' with ':' (and log a warning as a reminder to fix the
code?).
I prefer that more, but the question is which characters should be
reserved for CTRL syntactic purpoess, and which are free to use by the
applications to name elements of the CTRL string/node.
Any input to this? I personally would go for ':'. As CTRL is very
loosely modelled after sysfs, ':' also occurs frequently in sysfs names
such as '/sys/bus/usb/devices/1-3:2.0'
So we'd keep the '.' as path/node separator, and we use ':' as separator
inside counter (and possibly other) names, which is opaque to CTRL.
Opinions?
Should we further restrict the CTRL interface strings (and those of
systems exporting to CTRL) to standard US 7-bit ASCII with a limited set
of special characters such as ":-_@" but prevent any non-printable chars
or special chars like "{|}()~[]\^`'?<>=;/+*&%$#!"? I would support such
a motion. We could even make it more general and use that for all our
identifier strings and have a general validation function that all code
modules call whenever validating a string identifier used, such as e.g.
osmo_fsm names, etc.
Posted also to the mailinglist for further discussion/feedback:
http://lists.osmocom.org/pipermail/openbsc/2017-October/011263.html
