mdev

[Vladimir Dronnikov]

>> ... 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. That
is why I want_ed_ to delegate parsing to our unified parser, and to do
so we would have to require alias part... I drop that proposal, since
it indeed would break mdev compatibility.

>>
>> 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.

>> 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.

--
Vladimir