Use a specific device ?

[Jean-Christian de Rivaz]

Le 09. 06. 15 17:43, Dan Williams a écrit :
> On Fri, 2015-06-05 at 16:16 +0200, Jean-Christian de Rivaz wrote:
>> Le 05. 06. 15 15:51, poma a écrit :
>>> On 05.06.2015 15:37, Jean-Christian de Rivaz wrote:
>>>> Le 05. 06. 15 15:09, poma a écrit :
>>>>> On 05.06.2015 14:14, Jean-Christian de Rivaz wrote:
>>>>>> Le 05. 06. 15 13:18, Aleksander Morgado a écrit :
>>>>>>> On Tue, May 26, 2015 at 12:19 AM, Jean-Christian de Rivaz <jc at eclis.ch> wrote:
>>>>>>>> I have a system where the modem have multiple /dev/ttyACMx ports where x is
>>>>>>>> not constant because of the dynamic nature of others serial devices.
>>>>>>> It may be worth noting that a very similar issue with the one faced
>>>>>>> here is the one with network interface names, where interface names
>>>>>>> were created as kernel drivers probed the different interfaces, ending
>>>>>>> up with "eth0", "eth1" and so on. Then, there would be network
>>>>>>> interface configurations for each network interface based on the name,
>>>>>>> but no one really ensured that the name was the same upon reboots. The
>>>>>>> solution provided by systemd to ensure that the proper configuration
>>>>>>> is applied always to the proper interface is to make the device names
>>>>>>> "predictable", see:
>>>>>>> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
>>>>>>>
>>>>>>> This solution avoids the need of any other udev rules to e.g. create
>>>>>>> network interface names containing the device MAC address or what not.
>>>>>>>
>>>>>>> I'm wondering whether the same could be applied not only to network
>>>>>>> interfaces, but also to ttyACMs, ttyUSBs and cdc-wdms, and end up
>>>>>>> having predictable tty names like e.g. /dev/ttyACMp0s20u4i0. Sure,
>>>>>>> those names are a nightmare to type, but they are predictable (e.g. in
>>>>>>> this case by including the physical location of the connector of the
>>>>>>> hardware).
>>>>>>>
>>>>>> This would be a wonderful solution. The only problem is when will this
>>>>>> feature be available in a stable Linux kernel widely used by all majors
>>>>>> distributions? Until this dream happens (probably not before severals
>>>>>> years I guess), an other option must be implemented.
>>>>>>
>>>>>> Jean-Christian
>>>>> Face your broadband modem, live your dreams?
>>>>>
>>>>> Kay, when this would happen - Predictable Broadband Modem Interface Names?
>>>>>
>>>> I must emphasis that this solution will still not solve the ModemManager
>>>> problem of automatically probing any added serial devices, requiring all
>>>> non-modem serial device to add the ID_MM_IGNORE hack in udev rules. This
>>>> must change as soon as possible.
>>>>
>>>> Jean-Christian
>>>>
>>> MM probing various hardware, not much of a news.
>>>
>> But still a problem. The lack of proper use of udev by ModemManager
> What is "proper" use of udev here?
>
> Dan
>

By looking on how others types of device are handled, udev should be 
used to detect the type of a device in a way to let the relevant 
application manage it if the kernel did not have already a way to detect 
the type of the device (by using USB HID for example). The goal in this 
case is to have modem devices handled by a modem application like 
ModemManager or Ofono.

The most comfortable way for the users is to have a list of know devices 
type, usually based on some vendor and product id. This work generally 
very well for PCI and USB devices. The documentation should provide an 
easy way for a user to add and to submit to the project a new udev rule 
in case the product he use is not already in the list. The rules could 
be plain text udev rules under /lib/udev/rules.d/ (see for example 
40-libgphoto2-2.rules or 40-libsane.rules) or directly coded into the 
application like Ofono do for example, see 
http://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/udevng.c#n1065. 
I personally much like the plain udev rule because it allow easy 
experiment without changing the source code of the application. For 
example the last new modem I use on a embedded system is working good 
enough for me with the generic ModemManager plugin so it would be nice 
to let support it by just add a line in a udev rules file.

There are some cases where this is not enough, typically for the plain 
old ttyS* serial port and when the reported vendor and product id is 
just a generic serial port that can be connected physically to any 
serial device, not necessary a modem. In this case the distribution or 
the user should provides a udev rule to specify that there is a modem 
device connected to this particular serial port or to probe if there is 
a modem connected to it. Maybe he know the exact type of the modem, 
maybe he want to let the application probe the modem type, maybe he want 
to let the application detect if there is a modem or not. I have no 
strong opinion on how the distribution should set the default for this 
kind of ports, but I think this is important to let the choice to the 
distributions and to the users on how the serial ports are acceded by 
the application.

Jean-Christian