On Mon, Mar 05, 2018 at 11:28:49PM +0000, Holger Freyther wrote:
Hey,
pespin left a good comment about the question of how the MS driver and the GSM tester
could be better integrated. I was about to write some argparse code for the MS driver but
I think it is best to make this configurable as a scenario.
In terms of scenario knobs I can see:
- #MS
- CDF function
what's CDF?
- IMSI generator (start with XXX and count upwards)
We have MSISDN and I think LAC generated on-the-fly, with state in the
file system. You could basically copy-paste that MSISDN generator code to
make an IMSI generator.
- virtphy vs. trxcon?
(no idea)
The actual test would remain separate (and maybe turn
it into a suite at some point in the future). What do you think? What should I obey when
parsing/handling config?
The way I see it, you implement a "copy" of the mobile.py interface to,
instead of talking to ofono, talk to the virtphy/MS, whatever it's called.
(Like Pau said.)
Then either:
- We define a limited specific number of those virtual modems in the
resources.conf to be available, and add a specific trait, as in a 'type:
virtual' or something. You would then add a scenario that asks for the
modems to be of 'type: virtual', and run the exact tests from the
existing suites, just with virtual modems instead of physical ones.
- Or we could even auto-generate the entire virtual modem, sort of in the
way that we start core net components at the moment, by calling a
function from within the test case. For example, the osmo-msc is not a
resource handled in scenarios, we just ask for IP address resources and
hand one to the osmo-msc startup. Then there would be a separate
*suite* with its conf not even asking for any modem resources, just its
tests call a function that ask to setup virtual modems on-the-fly. A
drawback here is that you can't just re-run existing suites -- you can't
just swap out the physical modem kind for a virtual one and run the
exact same suite, you have to write different tests that launch virtual
modems from the test case script.
It depends on: a) do you want to run the existing tests on the virtual
modems at all? b) how physical/resource-like vs.
software-component-running-like is a virtual modem?
For virtual modem being a resource, I'd add only separate scenario
definitions and possibly add tests to existing suites if that makes any
sense; for virtual modems started up like a software component, I'd add an
entirely separate suite even for the first test implemented (because then
that suite wouldn't ask for 'modem' resources to begin with).
BTW, in general, a virtphy issue could be the multicast. I saw stsp having
some trouble keeping the multicast from seeping out of all the interfaces.
We probably want the osmo-gsm-tester to contain that somehow.
~N