Use a specific device ?

[Dan Williams]

On Tue, 2015-06-09 at 19:34 +0200, Jean-Christian de Rivaz wrote:
> 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.

ModemManager ships defaults that automatically probe ports for a set of
well-known drivers, but also ships blacklists for drivers/devices we
know aren't modems, and also ships greylists for non-plug-and-play
devices and USB<->serial adapters that might be modems, but often are
not (generic pl2xxx devices for example).  Upstream ships on the
permissive side.

But users and distros are certainly able to install additional udev
rules that blacklist/greylist more devices, and further restrict what
ModemManager probes automatically.  Using udev 217 and later, you could
definitely write your own rules to blacklist *everything*, and then
selectively un-blacklist using:

TAG-="ID_MM_BLACKLIST=1"

So I think the functionality you want is already present and a few udev
rules could do what you want.  But I think ModemManager will continue to
ship slightly more automatic rules upstream, and of course we will
continue responding very quickly to new blacklist/greylist rule
submissions.

Dan