This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20180306/93faa2dd/attachment.bin>