On 04/23/2013 06:34 PM, 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.
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.
*shameless bump*
-- Piotr.
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
