mdev

Denys Vlasenko vda.linux at googlemail.com
Mon Apr 13 14:00:54 UTC 2009


On Monday 13 April 2009 15:28, Vladimir Dronnikov wrote:
> >> ... the current parsing code is wrong.
> >
> > # cd testsuite
> > # ./runtest mdev
> > PASS: mdev move and command  <----------------
> >
> > That testcase checks that "sda 0:0 644 =block/ @echo @echo TEST"
> > is executed correctly.
> 
> Could you put a TAB instead of SPACE between "block/" and "@echo ...".
> The result would be in "@echo ..." command not found.
> IOW, the 4th field is parsed non-uniformly, and uses dumb
> strchrnul(string, '<SPACE-CHAR-HERE>') to split the field into alias
> and command. It is wrong with other valid delimiters like tabs.

Wow, bug indeed. Fixed in svn, thanks.

> >> Also, I'd like to have $SUBSYSTEM envvar set, as udev does, to be able
> >> to run commands for a whole bunch of devices regardless of their
> >> names. E.g. for all PNP devices it is good to load specific modules
> >> (if any).
> >
> > udev.c source has this:
> >
> >        action = getenv("ACTION");
> >        devpath = getenv("DEVPATH");
> >        subsystem = getenv("SUBSYSTEM");
> >        /* older kernels passed the SUBSYSTEM only as argument */
> >        if (subsystem == NULL && argc == 2)
> >                subsystem = argv[1];
> >
> >        if (action == NULL || subsystem == NULL || devpath == NULL) {
> >                err("action, subsystem or devpath missing");
> >                goto exit;
> >        }
> >
> > Looks like newer kernels already pass $SUBSYSTEM in env?
> > Or do they all still pass it in argv[1]?
> >
> 
> Hotplug events has $SUBSYSTEM set by the kernel. _Coldplug_ events
> (mdev -s) export no such variable. To extract it udev people use the
> basename of the value of "subsystem" symlink in the particular device
> directory (under /sys/). I'm preparing the patch for mdev to implement
> the feature.

Good to hear.

> >> Also, sometimes it is good to not stop at the first matching rules. It
> >> can be implemented, say, via config-time switch. The rationale is to
> >> reuse and generalize the rules as much as possible. I want, say, make
> >> all sound devices owned by root:audio with 0660 mode, but some of them
> >> I want to have 0666 mode. Two rules would do the magic.
> >
> > Can you give an example how these rules would look like?
> 
> Sure. Imagine we have subsystem matching rules mechanism (I propose to
> use leading-slash syntax). Then:
> ----
> /sound root:audio 660 =snd/
> (audio|dsp|mixer) root:audio 666
> ----
> should move ALL (even those which may appear in the future kernels)
> sound devices to snd/, and those mentioned in the second line would
> additionally set mode 666.
> Crystal clear syntax, IMHO.

I was concerned that with that option "last rule" with, say
.* 0:0 0600
will always execute, which will set any device's ownership
and mode. Many people wouldn't want it.

Moreover, options which _change_ behavior (as opposed to
_add features_) are not so desirable. It's better when
mdev always follows one rule, so that you do not need to guess
"was FEATURE_MDEV_CONF_KEEP_MATCHING on or off when *this*
mdev binary was built?".

How about a prefix char which means "do not stop on this rule
even if it matches"? A-la Makefile's dash:

-/sound root:audio 660 =snd/
(audio|dsp|mixer) root:audio 666

--
vda


More information about the busybox mailing list