RE: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Mike Edenfield]

From: Alan Mackenzie [mailto:acm@×××.de]
 Sent: Tuesday, March 13, 2012 7:04 PM

> Huh?  What's that to do with udev?  You're talking at far too high a level
of
> abstraction.  The new hardware will "just work" if there are the correct
> drivers built in.  That's as true of udev as it is of mdev as it is of the
old static
> /dev with mknod.

This idea works fine when your drivers are simple enough to go into a
kernel, and can actually perform all of the functions your device needs.
Many modern devices require "complex" things to happen before or after they
appear in your /dev tree before they can *really* be useful. (Complex
relative to the operations a kernel module is expected to perform).

When I plug in my HP USB printer, the hplip system checks a locally
installed database file to make sure I have support for that model before
making it available as a device. When udev finds my Bluetooth keyboard or
mouse, it launches bluetoothd so it will work. udev manages drives, sound
cards and network cards that may appear and disappear in such a way that
they are always given consistent names. I have custom rules that run when I
plug an Android phone into my machine that preps it for being debugged via
Eclipse, despite the kernel seeing it as just a generic USB device.

The point is, udev suppors /arbitrary/ behaviors, defined by device vendors
or even end users, which can be controlled and configured at runtime.  Some
of these operations would be hard to do safely from the kernel. Some of them
may even trigger events to happen in userspace in the context of the
logged-on user (such as automounting from GNOME.)

Note that none of this is necessarily unique to udev; mdev could (and
probably  does, I don't know) provide userspace events for new devices just
as easily as udev does. But in order for udev to maintain the broad level of
complex hardware support that it has, it must make certain assumptions that
may not hold true for /all/ cases, but are true in the /broadest general/
case: that it may be required to launch software or read data found in /usr
or /home or wherever else a udev rule might point, and it may be required to
do so before it has even seen the device nodes needed to mount non-root
partitions.

mdev's appeal here in this case is simply that it makes different, simpler
assumptions: that it will /never/ need to access software or data that is
not part of the root partition at boot time. If that assumption holds true
for a given system, then mdev can behave as an effective drop-in replacement
for udev. The choice is then to give up support for the broader case in
exchange for a simpler system that supports "enough" to make all of your
specific hardware function.

--Mike