Hi Holger,

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
idea earlier.

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
not full.


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.


Middle 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 
resource?

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

Reply via email to