From: Alan Mackenzie [mailto:a...@muc.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
