[systemd-devel] Use a specific device ?

[Dan Williams]

On Tue, 2015-06-09 at 21:22 +0200, Jean-Christian de Rivaz wrote:
> Le 09. 06. 15 19:52, Dan Williams a écrit :
> > 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.
> >
> 
> This black list, grey list, and white list system is a mess and have to 
> die. No other application do that way because this is completely against 
> the common sense. It like saying that by default every house is your and 
> that the others have to send to you a list of the houses where you must 
> not enter without invitation. All others applications use udev to select 

It's a simple numeric calculation.  The number of items in the whitelist
would be far, far greater than the number of items in the blacklist.
You also may not realize how many modems are released each year, how
many manufacturers make them, and how many models/variants there are...

The number of non-modems that are driven by the same drivers as modems
(eg, cdc-acm, pl2xxx, ftdio) is much, much smaller than the number of
modems driven by those same drivers, and so we blacklist them instead.

Again, we will respond quickly to new requests for blacklist/greylist to
ensure that ModemManager doesn't probe UPS or whatever.

> the appropriate device, not to reject inappropriate device. This is an 
> abuse of the udev technical capabilities. Yes there exists a few other 
> udev blacklist rules, but there are clearly for exceptional cases. 
> ModemManager try to make the abuse a general concept and this is bad. 
> Try to think I bit more globally and imagine the mess if every 
> applications do that way. Imagine the /lib/udev/rules.d/ with only black 
> list rules for every possible types of devices... Can you seriously 
> thing that distributions and users will be happy with a such chaotic system?
> 
>  From the current /lib/udev/rules.d there is already 16 files for 
> ModemManager only and 5 of them are just for black/grey/white list. This 
> is ridiculous. The ID_MM_BLACKLIST idea was terribly wrong. I hope the 
> ModemManager will understand that some transition would be an advantage 
> for everyone.

I don't agree.  A whitelist would have two consequences: (a) many, many
modems would not work out of the box, and (b) we would be spending much
more time updating already-out-of-date whitelists and kernel drivers
than we would adding features and capabilities to ModemManager.

Dan