> On 6. Mar 2018, at 12:20, Pau Espin Pedrol <[email protected]> wrote: > > Hi,
Hey Neels, Pau, > I guess you are referring to my comment in [1]. You can reuse suite and > resources management utilities already present in osmo-gsm-tester. The > easiest way to do that would be to create a new implementation for class > Modem which would start a mobile process underneath. Then in suite() when > requesting a modem add a function to allocate class ModemOfono or > ModemOsmoMobile based on config type, similar to how it is done for different > bts (see example/resources.conf and src/osmo_gsm_tester/suite.py). 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. From my point of view: Middle step: Use the test scenario configuration (maybe even the suite class). Make the UL test reusable (and extend to SMS and Calls) 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? 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. Need to add primitive to register a FD so lua can get an answer back. Find a way to set SO_PASSCRED on the socket to have "mobile" reachable by the event server as well. Could be a lua binding or we patch lua socket Have a lua script that forwards the "on/off", "limit to cell XYZ", "Send SMS", "Place Call", "Open Call and read data from this socket" Missing primitives for mobile. But we need them anyway. The middle step is in-reach, the big step will take some real time and I could use some help (e.g. the event loop integration). > I think that CDF functions and IMSI generation and alike are really attach to > the test and they are really not resources, so no need to "configure" them. > This topic matches with your other mail thread too. The "SIM" card would need to be in the device so IMSI kind of belongs to the resource?
