mdev

[Rob Landley]

On Sunday 19 April 2009 06:29:21 Denys Vlasenko wrote:
> > udev doesn't enumerate _devices_. It replays hotplug events by echoing
> > "add" to any /sys/devices/*/*/uevent and then handles hotplug events
> > storm via its hotplug daemon.
>
> I think mdev -s should not do that, because some users may intentionaly
> want to _not_ load any modules except those they already did,
> and they don't care about devices which exist, but have no module
> loaded (yet). They *want* them to stay uninitialized.
> IOW: they are happy with the way curremt mdev -s works.

I admit that "rmmod" is an easy way to quiesce a device so it doesn't eat 
power.

> We can either recomment users which do want this behavior to use
> shell script, or we can add another option to mdev.
> BTW, this will load again already loaded modules, are redundant
> modprobes always harmless?

The kernel won't load the same module twice.  Modules have to be able to 
handle multiple devices.  I believe this has always been the case.

> > That daemon is given configurable rules
> > of extensive syntax. One of the most useful rule is to fire modprobe
> > once the action is "to add" and $MODALIAS is nonempty.
>
> How such hotplug event look like, for example, for serial ports?
>
> $ACTION = add
> $DEVPATH = /class/tty/ttyS0
> $SUBSYSTEM = tty
> $MODALIAS = ???

The only way you could actually hotplug a serial device would be by plugging 
in a usb->serial converter (which doesn't show up as ttyS0, it's ttyUSB0 in 
mine).  Conventional 16550a chips are soldered in place and don't even 
provide any link status to tell you when a cable's plugged in.  So the only 
place this hotplug event could come from is via root creating it 
intentionally (via modprobe or echo add).

I've yet to encounter a serial device that consumes less power when it's 
unconfigured, so I don't know why you would want this as a module instead of 
a static driver.

> If module is not loaded, echoing "add" to /sys/devices/*/*/uevent
> for serial port generates such event, but /class/tty/ttyS0/dev
> does not exist - do I get it right?
>
> My proposal was to have
>
> [-]VAR=VAL 0:0 0600 @CMD

My understanding is that:

A) Neither MODALIAS nor FIRMWARE actually care what the value _is_, just that 
it's set.

B) The behavior for both is the same every time, FIRMWARE means do firmware 
loading, MODALIAS means call modprobe.  There isn't really anything else they 
_can_ mean.

So there's nothing for the config file to actually _specify_, except 
boilerplate that's exactly the same for every single person that wants this 
support.

> (we can detect the syntax by looking for =, maybe also
> checking that VAL is [A-Za-z0-9_]*)

Or you could have the wrapper script handle environment variables that mdev 
doesn't care about.

> We can then have "MODALIAS=.* 0:0 0600 @modprobe $MODALIAS" rule
> and mdev needs to be taught to scan conf file even if $DEVPATH/dev
> is missing. (Naturally, it will not create /dev/xxx yet,
> it does not know maj:min)
>
> What happens after modprobe's success? Does $DEVPATH/dev appear?
> (At once or after a delay?)

Depends on the module.  In theory modprobe shouldn't return until the devices 
are initialized, but I don't believe that actually guaranteed.

In theory, the hotplug infrastructure should generate a fresh "add" event once 
the driver has spawned a /sys/{class,block} entry for the sucker with a "dev" 
file under it.  (It has to do this because you could modprobe from the 
command line at any time.)  So the logical thing to do would be for mdev to 
exit and wait for the other hotplug event to call it back, which again brings 
up the "why is this in mdev" topic again if this is an isolated codepath that 
never calls the rest of the mdev code in the same instance...

> Does it generate another hotplug event 
> or do the same mdev invocation need to finish creating /dev/xxx?

I think it has to generate another hotplug event or it couldn't respond to you 
calling modprobe from the command line.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds