mdev

[Vladimir Dronnikov]

>> All hotplug processing could then be moved to a separate applet (hotplug,
>> say), make_device() would be shared among them.
>
> Unfortunately, it's not that simple.  The mdev -s code is one way to
> trigger /dev creation fro the information the kernel exports in sysfs, and
> the hotplug stuff is another way of feeding essentially the same information
> in to the same code.  Both of these code paths have to create the same device
> nodes and parse the same config file, so splitting them isn't as much fun as
> you'd think.

So the two parts should be placed in the same mdev.c: just copy-paste
mdev_main() and rename one copy to hotplug_main(). Then remove
unnecessary branches from either. I want them share make_device(), but
do not want to struggle in the trade for "mdev -s"
speed/functionality.

>> I do not concern "mdev -s" coldplug speed.
>
> The reason mdev was written in the first place is that the coldplug speed was
> abysmal.  I had a shell script version that did it back in 2005 (it came
> first), and it was converted to C because it could take 10 seconds to run.

I meant speed here is not of my primary concern. And you here do not
concern of missing events, right? mdev doesn't not call make_device()
for those devices that have no "dev" entries. How to be with serials
ports and network interfaces? On modular kernels the former never get
appeared, the latter never get a chance to be netif'ed or initialized.
Embedded people might have compiled their kernels moduleless and
all-inclusive, but I don't.

This contradiction makes me shut-up for "mdev -s" (coldplug) part of
mdev -- I don't want users to hate me for changes they don't need. So
I want coldplug to not change. But the hotplug part of mdev surely
should be changed: added at least $MODALIAS support. Or $FIRMWARE is
quite useless, since firmware is binary data needed by modules.

>
> If you didn't care at all about speed, what you'd do is iterate through /dev
> and echo "add" to each uevent file to trigger a new hotplug event after boot.

That is udev's approach. Slow, yet reliable.

>> I can live with shell script
>> enumeration of uevent files, thus totally do not need "mdev -s"
>> portion. But I urgently need hotplug portion. In order to not fork a
>> new applet I was "tuning" mdev itself. We should definitely separate
>> mdev into {cold,hot}plug parts, so people can what they need.
>
> That seems a significant step in the wrong direction to me.  You're turning
> one applet into two, but making them share the biggest and most complicated
> parts of their code.
>

What else to do if mdev's purity is a saint cow, Rob? I really like to
go along the stream and do not have local patches, but I miss many
nice features. And I don't want do return to udev. I'm trying to
advance, using any mean, and sometimes to not loose everything one
should retreat.

>> > All this cold-versus-hotplus things, $MODALIAS, $SUBSYSTEM -
>
> They didn't _exist>
> Rob
> --
> Latency is more important than throughput. It's that simple. - Linus Torvalds
>

_ when I wrote mdev.  Note that sysfs _has_no_stable_api_.
> Never did, probably never will.

But they do exist now. And as any useful existance, should be
employed. Again, I can replay coldplug module loading events with:
# find /sys/devices/ -name modalias | xargs -r cat | xargs -r modprobe -qa

But what to do with hotplug events that specify modules to be loaded?

Denys proposed to use any environment variable matching -- that way we
could get rid of $MODALIAS and $FIRMWARE processing in C. What do you
think of?

Best regards,
--
Vladimir