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