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