Use a specific device ?

[Jean-Christian de Rivaz]

Le 05. 06. 15 13:43, Aleksander Morgado a écrit :
> Hey,
>
>>>>> I you follow the previous paragraph, you will understand that it's
>>>>> clearly the job of ModemManager. This just plain logic as this is the
>>>>> only entity in the chain that receive the udev event about the modem.
>>>> I don't necessarily think it is ModemManager's job.  Since what you want
>>>> in the end is to tie a specific NM connection to a specific modem (based
>>>> on type, slot #, whatever), it's the job of NetworkManager to figure
>>>> that out for you.  ModemManager can certainly help if we can figure out
>>>> a clean generic way to do that.
>>> FWIW, I agree here.
>>>
>>> Once you have more than one modem/SIM/operator/whatever, then you cannot
>>> automatically do-the-right-thing-for-everyone.  You can select
>>> reasonable defaults of course, but the final modem selection policy
>>> should be user controlled.
>>>
>>> There is no way MM or NM can know that one of my modems dont' have any
>>> antennas connected, or that my operator only allows 3G so that LTE is
>>> irrelevant, or that my internal modem tends to overheat, or ... I'm sure
>>> you get the point.
>>
>> This is clearly the MM jobs to a least make those information available to
>> D-Bus.
>>
> Still, that is not that clear to me.
>
> ModemManager does already make all the modem-related information
> available in DBus. In particular, MM already exposes the real device
> names of the TTYs, cdc-wdms and WWAN netdevs being used for a given
> modem.
>
> But ModemManager does not track any modem-specific or SIM-specific
> configuration; upper layers (e.g. NetworkManager) do this. Therefore,
> if other applications (e.g. NetworkManager) need to track specific
> configurations with specific devices, they could add udev flags
> themselves and track them themselves. Or they could track symlinks to
> the ttys (like /dev/modem) themselves, by using
> g_udev_device_get_device_file_symlinks (). Updating the ModemManager
> DBus API with information that others can already gather themselves
> doesn't look like a good idea. Another thing would be if the others
> were not able to do so and if ModemManager was the only one able to do
> so (e.g. SIM ICCID, IMEI, IMSI...), but this is not the case.
>

ModemManager project can alway ask others projects to fix problem he 
don't want to solve, but at some point ModemManager project must realize 
that he are pushing against how udev is designed. The normal use of udev 
is to detect the purpose of a added device, based usually on the vendor 
and product id, and to call the application that is designed to handle 
the purpose of the device. Why ModemManager still don't use this schema, 
that any others projects agree on, is a mystery. Stop asking 
NetworkManager to use udev to find information about the device. The raw 
real fact is that ModemManager is unable to publish a stable name for a 
given modem on D-BUS precisely because ModemManager don't use udev in 
the normal way.

>>> Even simple things like internal vs external might be hidden from MM.
>>> All modems are connected by USB to the same controllers.  We do have the
>>> port/connect_type attribute nowadays, but that information comes from
>>> the PC firmware (ACPI), and we can be pretty sure there is at least one
>>> system getting it wrong.
>>
>> No, what you are talking about here is the udev job. And yes, an user could
>> have a use case to select a modem based on the port/connect path. An other
>> user could have a use case to match a specific modem product id. This is the
>> advantage to use udev: it let the choice to the user. The standard why to
>> manage devices on Linux today is to provides a list of udev rules that match
>> the know devices on the market. This is why there is a /lib/udev/rules.d and
>> /lib/udev/hwdb.d directories in your distribution. MM try to auto probing
>> every serial ports, nobody do that anymore with udev. MM should only auto
>> probe to find the good port on multiple port modem.
>>
>>> Every system and user is different. Policies have to be user defined.
>>> Which implies configuration. So NM is the lowest level where you can
>>> make this decision.
>>>
>> Certainly false: udev is the lowest level. There are reasons why MM already
>> use udev variables.
>>
> Yes: we use udev variables when we cannot query the modem about the
> purpose of the different ports, we use udev to flag specific port
> types. This udev variables are needed for a correct operation of
> ModemManager But this doesn't open a door to add udev rules to be
> parsed and exposed by ModemManager for whatever other purposes that
> users of ModemManager may have. NetworkManager is just one user of
> ModemManager, not the only one.

And NetworkManager is not the only one ModemManager client having 
problem because ModemManager can't publish a stable name for a given modem.

> If there is a need to manually manage udev variables to track specific
> configurations for specific devices, then ok, do that, that's fine.
> But asking ModemManager to read  those variables and expose them in
> ModemManager's own DBus APIs is not the way to go, I think...
>

It's not a specific configuration problem, this is simply to have a 
stable name for a given modem. That said, I really hope that one day 
ModemManager stop automatically detecting a modem on any serial port 
that don't have the udev ID_MM_IGNORE hack. ModemManager must only 
automatically detect the right ports across the multiples ports of a 
specific modem. There is currently no other way than using udev to do 
that. Others projects have understand this many years ago.

Jean-Christian