On 04/02/2013 02:35 PM, Denys Vlasenko wrote:
Mystery solved.
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.
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, 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?
-- Piotr.
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
