[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: "mdev: remove undocumented subsystem/devname matching hack" disaster.
From:       Piotr Karbowski <piotr.karbowski () gmail ! com>
Date:       2013-04-23 16:34:57
Message-ID: 5176B831.40403 () gmail ! com
[Download RAW message or body]

On 04/02/2013 04:08 PM, Piotr Karbowski wrote:
> On 04/02/2013 03:46 PM, Denys Vlasenko wrote:
>> On Tue, Apr 2, 2013 at 3:31 PM, Piotr Karbowski
>> <piotr.karbowski@gmail.com>wrote:
>>
>>> On 04/02/2013 02:35 PM, Denys Vlasenko wrote:
>>>
>>>> The invocation which sets wrong ownership has $DEVNAME set:
>>>>
>>>> mdev[730]: 56.531462 ACTION:add SUBSYSTEM:sound DEVNAME:snd/controlC0
>>>> DEVPATH:/devices/pci0000:00/**0000:00:1b.0/sound/card0/**controlC0
>>>> mdev[730]: dev 116,5
>>>> ...
>>>>
>>>> If $DEVNAME is set, we don't guess device name to be basename
>>>> of $DEVPATH, we use $DEVNAME instead
>>>> (because it looks like a better choice).
>>>>
>>>> "snd/controlC0" won't match "control.*       root:audio 660 =snd/"
>>>> Last catch-all rule gets matched instead:
>>>>
>>>> mdev[730]: rule matched, line 111
>>>> mdev[730]: mknod snd/controlC0 (116,5) 20660 0:0
>>>> mdev[730]: running: /opt/mdev/helpers/catch-all
>>>>
>>>> This looks less than ideal, but I don't see immediate ways
>>>> to improve it. Ideas?
>>>>
>>>>
>>> Well, that's awkward, because mdev -s  see 'controlC0' but the mdev as
>>> hotplug agent after modprobe see it as snd/controlC0. I can imagine that
>>> this affect everything not only sound system. Would it be possible to
>>> restore how it was handled in older mdev? Otherwise that would
>>> require some
>>> heavy lifting regexes to handle it and some of the results can be far
>>> from
>>> desired result.
>>>
>>
>> It would require duplication of rules, yes.
>> I don't like this detail either.
>>
>> In some cases you can have one rule
>> by matching $DEVPATH:
>> DEVPATH=.*/control.*;.*   ....
>
> reworking most if not all rules with DEVPATH= does not looks really nice.
>
>>
>>> Woudn't it be better to 'basename' it? Because if the module is
>>> loaded or
>>> compiled in-kernel, it will be just 'controlC0', and I was pretty sure
>>> kernel never-ever provide subdir in DEVNAME,
>>>
>>
>> Looks like kernel provides subdirs in $DEVNAME (now).
>>
>>
>>> even the msr/cpuid support in kernel with help desc about /dev/cpu
>>> used to
>>> be created in bare /dev. The old mdev was using basename, and I see
>>> no real
>>> reason to not keep this as-it-was, what you think?
>>>
>>
>>> From $DEVNAMEs I saw it looks like using it makes sense:
>> kernel already tells us the subdir, no need to code it up
>> in the rules.
>
> If so, then mdev -s needs a way to support this, somehow to get the
> snd/X, if that's not possible, I would highly suggest to basename $MDEV.
>
> Other, ugly but possible workaround would be for me to put a thingy in
> catch-all script to check if $MDEV contain slash (and since it hit
> catch-all it wasn't handled), if it does, then basename it, export MDEV,
> DEVPATH etc and exec /sbin/mdev. Sounds better than in-mdev basenaming it?

Hey Denys, any news or comment on this? I'd like to roll out new mdev on 
some of my deployments however I don't want do any workaround like 
described above if thats not desired solution to this very issue.

-- Piotr.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]