mdev

[Denys Vlasenko]

On Sunday 12 April 2009 18:20, Vladimir Dronnikov wrote:
> mdev_notes_usage contains only three fields definition (plus optional
> command field).
> But 4th field can be symlink definition either, right?

Hmmm. Usage text needs fixing.
> 
> So I'm starting to lose the path: can one specify (I need that for
> sure) both symlink definition and command to execute on device
> creation/deletion?
> If so, then the current parsing code is wrong.

# cd testsuite
# ./runtest mdev
PASS: mdev add /block/sda
PASS: mdev stops on first rule
PASS: mdev move/symlink rule '>bar/baz'
PASS: mdev move/symlink rule '>bar/'
PASS: mdev regexp substring match + replace
PASS: mdev command
PASS: mdev move and command  <----------------
PASS: mdev #maj,min and no explicit uid

That testcase checks that "sda 0:0 644 =block/ @echo @echo TEST"
is executed correctly.

> Wouldn't it be better to require all five fields be present using,
> say, a dot as a placeholder for unused field? This would make
> mdev.conf less cryptic. (BTW, is there any standard mdev.conf, as udev
> has its rules.d/?)
> 
> 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]?

> 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?
--
vda