[systemd-devel] Use a specific device ?

Dan Williams dcbw at redhat.com
Wed Jun 10 12:51:33 PDT 2015


On Wed, 2015-06-10 at 20:52 +0200, Jean-Christian de Rivaz wrote:
> Le 10. 06. 15 16:36, Dan Williams a écrit :
> > On Tue, 2015-06-09 at 21:22 +0200, Jean-Christian de Rivaz wrote:
> >>
> >> 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 various black/grey/white lists of ModemManager are together already 
> one of the top biggest udev rules list, and there are very incomplete 
> because there is a lot of industrial products that still use serial 
> ports for specific command and control. The first reason why the list is 
> not growing is that only a few peoples know that there need to blacklist 
> there non modem products. I completely disagree about the argument that 
> a white list will be too big. There is not so much modem manufacturers 
> and each of them don't even release a new product range per year. The 
> 40-usb_modeswitch.rules required by some modems is not so big either. 
> Really this is not so different to the gphoto2 or sane udev rules lists.

In my experience this is not true.  Many vendors, many of them no-name
Asian ones, release many devices each year, especially when rebranding
the same device between network operators.  Even in the United States
there can be 3 or 4 models of the same hardware, differentiated only by
firmware and external branding, but with different VID/PID combinations.

> But most important is to understand that the current ModemManager is 
> abusing the udev concept and confusing the users. Are you really serious 
> when you ask a random people with a new UPS product to add a new udev 
> rule to the ModemManager project? I think you are so focused on 
> defending the current ModemManager abomination that you fail to see the 
> problem from the point of view of a common user. The length of a white 
> list is not an excuse to not fix the problem.

I'm sorry we disagree, and in a perfect world a simple whitelist would
suffice; I agree with you here.  But unfortunately it's not perfect, and
I know this well from the last 8 years working on ModemManager and its
predecessor.  I'm not sure there's anything more I can add to this
conversation.

Dan

> >> 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.
> >
> 
> As I have say before, please let the choice to the distributions and to 
> the users. I never asked to completely remove the auto probing feature 
> of ModemManager, I ask to have more control on it and to make it not the 
> only possible ModemManager mode of operation. A transition plan could be 
> to still auto probe by default udev rule but with a way that allow 
> reporting the modem vendor/product id if he is not already in the list. 
> This will solve (a). For (b), my point of view is exactly the opposite: 
> if ModemManager will allow to select the features set of a modem from a 
> udev rule using variable, then advanced users can try to enable more 
> features on a new modem by just writing a udev rule. Very powerful and 
> without having to compile a new code.
> 
> Jean-Christian
> 
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel




More information about the systemd-devel mailing list