thanks to both of you for the detailed responses. I like the idea, it
solves the coordination between setting up the core network and the
phones. The approach looks generally feasible and I wish we had this
Unfortunately I had only planned to do LUA bindings, the orchestration
was already an extra and I blew all my time in trying to make asyncio
work and the scaling/concurrency issues with python. My intention with
the original mail was to find a middle step. Better integration but
I know some of the concepts in osmo-gsm-tester are quite complex to
grasp (lots of specific stuff like scenarios, resources, etc.), and some
of the required stuff is still missing (like better poll loop, managing
arfcns, etc. we have tasks created for them). As it's quite a bit amount
of work and it was not your primary focus, I don't expect to have
everything done in one step. Merging it as a separate env then slowly
moving it into osmo-gsm-tester seems fine for me.
Personally I was also lacking a better understanding on how mobile
operates and the resulting work of the lua bindings, as I didn't play
with it yet. Seeing your patches helped me a lot understanding better
what is there and where can we go from this first step.
Use the test scenario configuration (maybe even the suite class).
Make the UL test reusable (and extend to SMS and Calls)
What do you mean with reusable here? Can you explain it a bit more? Do
you mean being able to use other Modem implementations? I agree with that.
Big step (as proposed):
The "scheduling"/slow start is not like any of the existing tests (there
are conceptual difference of fail/pass handling when launching 10k procs)
The event loops need to be integrated. Not sure how to integrate this with
glib loop for glib-dbus?
I think the best would be having our own loop, which then also polls
glib loop in the process. As far as I remember glib provides APIs to get
poll notifications (via fd?) in case an event from them is triggered. If
I recall correctly EFL libs have APIs to do that for apps which want to
run efl+glib at the same time.Probably Qt guys do the same.
Other possibility would be to have our own loop which is internally
implemented using glib one.
Having a better loop was not a hard requirement until now because we
were fine without fine-grained time lapses and just active polling every
0.1 seconds, but I'd really like having a better loop.
I'll try to find some time in next days to have a look at improving the
current event loop.
A base class for a MS (or ME) without being ofono specific and simple enough.
Currently the lua JSON code is only from MS->Test.
I can help you with that, given that you provide all the lua specific parts.
The "SIM" card would need to be in the device so IMSI kind of belongs to the
An IMSI belongs to the resource, but the generator itself can be used in
different tests. The IMSI field in the Modem resource is there for
historical reasons (for instance if you'd like to force a specific IMSI
by default), but we should rework ModemOfono to get the IMSI from
ofono/dbus instead, since we are finally not using the IMSI to identify
the modems but its sysfs path.
- Pau Espin Pedrol <pes...@sysmocom.de> http://www.sysmocom.de/
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte