On Wed, Sep 27, 2017 at 09:34:22PM +0800, Holger Freyther wrote:
IIRC it was modeled like a property/sysctl. E.g.
kernel.sched_domain.cpu0.domain0.min_interval
one could say variable is "kernel.sched_domain" and parameter is "cpu0"
There's indeed a lot more going on than I was aware of, thanks! I can send, with current libosmocore master:
GET 123 status-ps.imsi1234567898765
and it ends up in the status-ps command implementation. (The cmd->value remains empty, cmd->variable is "status-ps.imsi1234567898765")
Also we do have a concept of nesting CTRL nodes separated by dots in the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().
I notice though that we do still have open doors for a lot of nonsense being sent to it without proper validation or error messages.
GET 42 existing-variable.trailing.names.ignored more nonsense following being ignored
in effect is identical to:
GET 42 existing-variable
So we should probably enforce that there is no ignored nonsense...
Should we also enforce a numeric command ID?
GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command
Going back to the OsmoHLR CTRL commands -- they are implemented in a way that doesn't match the CTRL interface ways. Let's collapse them.
SET enable-ps <IMSI> SET disable-ps <IMSI> SET status-ps <IMSI>
==>
SET subscriber.by-imsi.123456789098765.ps-enabled 1 SET subscriber.by-imsi.123456789098765.ps-enabled 0 GET subscriber.by-imsi.123456789098765.ps-enabled
We can also expand this later to things like
GET subscriber.by-imsi.123456789098765.status SET subscriber.by-imsi.123456789098765.msisdn 2345 GET subscriber.by-msisdn.2342.status SET subscriber.by-msisdn.2342.ps-enabled 0 GET subscriber.by-imei.987654321234565.imsi
yes?
We could leave the enable-ps, disable-ps, status-ps commands in place in case anyone is using it yet. I assume no-one is though.
~N