Use a specific device ?

[Jean-Christian de Rivaz]

Le 10. 06. 15 21:51, Dan Williams a écrit :
> 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.

Please provides real substantial example.

>> 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.
>

I am pleased that you agree on some point. Why did you not comment on 
the transitional proposition in my next paragraph?

>>>> 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
>
>