mdev

Rob Landley rob at landley.net
Fri Apr 17 08:27:18 UTC 2009


On Friday 17 April 2009 01:21:27 Vladimir Dronnikov wrote:
> > Guys, please, *cooperate*. Don't brush aside Rob's concerns,
> > convince yourself (and try to convince him) that what you do
> > is really necessary.
>
> AFAIKS the only intention Rob had was to just mknod for
> /sys/class/*/*/dev. As such "mdev -s" can be left as "mdev". All
> hotplug processing could then be moved to a separate applet (hotplug,
> say), make_device() would be shared among them. For I definitely
> understand Rob being sad of watching his crystal clear code becoming a
> "monster".

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.

> > Also, Vladimir, can you be a little more thorough when you
> > code up a change?
> > mdev had so much activity last days, it's hard to keep up
> > when I need to write testcases and documentation for you.
>
> There is way little feedback. The ideas change, the code changes. 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.

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.  
And it would be much slower, and spawn hundreds of new temporary processes, 
and would be better done as a shell script rather than in C.  (And 
potentially have memory usage spikes since you don't limit the number of jobs 
spawned in parallel, which was why the netlink code path was implemented.  So 
the IBM guys could get udev could scale on s390 mainframes without thousands 
of devices.)

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

> > All this cold-versus-hotplus things, $MODALIAS, $SUBSYSTEM -
> > you learn all these things but you do not write up
> > a HOWTO for the next guy - like me, or Natanael.

They didn't _exist_ when I wrote mdev.  Note that sysfs _has_no_stable_api_.  
Never did, probably never will.  Yes, I've participated in flamewars about 
this on linux-kernel, and bothered the developers in person at various 
conferences until they're sick of talking to me.

> > I don't yet use mdev, sure will be very happy if someone
> > documented their experience of switching from udev to mdev.
> > Please do so in docs/mdev.txt
>
> Let us settle down the code, Denys. I got stuck when I start to write
> docu...

It seems like code comments would be the most useful documentation.  I didn't 
even know until recently that the BusyBox.html#item_mdev docs were no longer 
current and that docs/mdev.txt had shown up instead.  The code didn't mention 
it, and the old documentation didn't mention it.

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


More information about the busybox mailing list