On Tuesday 23 April 2013 18:34, Piotr Karbowski wrote: > 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 > >> <[email protected]>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.
Looks like getting snd/X is not possible > > 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. I don't know. I don't want to ignore $DEVNAME. Its information is too useful. Maybe we need to teach kernel to export DEVNAME in sysfs. Or maybe devtmpfs is the way forward. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
