Hi Pau,

As far as I understand the IMEI is available in org.ofono.Modem.GetProperties "Serial" property. To be able to access this information, I need to previously power on the modem (SetProperty Powered true), otherwise it doesn't show up. Which means that for an ofono user, it is a requirement to power on the modem and thus use it before being able to identify it.

Correct, but why is this a problem? Under normal circumstances the modems are auto-powered by connman anyway. That's the only reason that oFono doesn't do this automagically.


Simple case: Several modems attached to a PC, in order to find the one I'm interested in I need to power on all of them and find which one matches a given IMEI. Really? Do I need this if I know where is my device always physically attached? Are you going through all your network interfaces and check against its MAC address to find the one you are interested in? Or you configure your network manager based on interface names? Would you enjoy it if your enp0s25 interface was suddenly named enp1s67? Specially if you have iptables rules, I bet that's going to be funny.

More complex case (my scenario): Again, I repeat: To identify a modem, as of now, you seem to require to power it on (use it, change its state) before identifying it. Now think of a system which has a config file with modems available on the system (with its dbus paths) and a resources database of modems (and other types of resources) currently in use. Now imagine several processes reserving any specific subset of modems with specific capabilities (in parallel) against the resources database, then using them and among the use cases they power off and power them on. Even if you have locking mechanism in the database, it's a nightmare, because again, you must use a modem before identifying it, meaning you either race condition with other processes using the modem you are identifying (eg. by powering it on, or leaving it powered on after identifying it, or while powering it off after identifying while other process is starting to use it).
oFono doesn't expose hardware details, only hardware capabilities. So I understand how this is helpful for your usecase, but I'm not convinced this is relevant for what oFono was designed to do.


Then the easy way: Each modem is assigned a unique persistent path, and that's the one always being presented and used. No need to identify it, I already know which modem is which. If I have several system setups, I can assign same names in all systems for easy use, etc. >
So the question should be better: Why should it NOT be deterministic?


In general oFono does not use deterministic paths, the Manager APIs should be used to query the list of objects. In fact the docs even specifically state that the modem object path might have a variable prefix (e.g. a random number) and that variable prefix can change across oFono boots. This is mainly to encourage UI/client writers to use the APIs properly.

We have used hardcoded paths in one or two cases for synthetic test cases (e.g. stktest) but those are highly special and not user-visible anyhow.



How are you making sure that dbus path is valid?   ofono_modem_create can fail after all...

Yes, it can fail while validating the path (dbus_validate_path) which is expected if a bad OFONO_PATHMNAME is supplied. If it's fine for you, I can add an error message there stating that dbus_validate_path failed and printing the pathname. Agree?

Go ahead and send a V2, I'll let it sit for a week or so to see if anyone else gives any feedback.

Regards,
-Denis
_______________________________________________
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Reply via email to