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-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel