--- /dev/null
+ udev and devfs - The final word
+
+ December 30, 2003
+ Greg Kroah-Hartman
+ <greg@kroah.com>
+
+
+Executive summary for those too lazy to read this whole thing:
+ I don't care about devfs, and I don't want to talk about it at
+ all anymore. If you love devfs, fine, I'm not trying to tell
+ anyone what to do. But you really should be looking into using
+ udev instead. All further email messages sent to me about devfs
+ will be gladly ignored.
+
+
+First off, some background. For a description of udev, and what it's
+original design goals were, please see the OLS 2003 paper on udev,
+available at:
+ <http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf>
+and the slides for the talk, available at:
+ <http://www.kroah.com/linux/talks/ols_2003_udev_talk/>
+The OLS paper can also be found in the docs/ directory of the udev
+tarball, available on kernel.org in the /pub/linux/utils/kernel/hotplug/
+directory.
+
+In that OLS paper, I described the current situation of a static /dev
+and the current problems that a number of people have with it. I also
+detailed how devfs tries to solve a number of these problems. In
+hindsight, I should have never mentioned the word, devfs, when talking
+about udev. I did so only because it seemed like a good place to start
+with. Most people understood what devfs is, and what it does. To
+compare udev against it, showing how udev was more powerful, and a more
+complete solution to the problems people were having, seemed like a
+natural comparison to me.
+
+But no more. I hereby never want to compare devfs and udev again. With
+the exception of this message...
+
+The Problems:
+ 1) A static /dev is unwieldy and big. It would be nice to only show
+ the /dev entries for the devices we actually have running in the
+ system.
+ 2) We are (well, were) running out of major and minor numbers for
+ devices.
+ 3) Users want a way to name devices in a persistent fashion (i.e. "This
+ disk here, must _always_ be called "boot_disk" no matter where in
+ the scsi tree I put it", or "This USB camera must always be called
+ "camera" no matter if I have other USB scsi devices plugged in or
+ not.")
+ 4) Userspace programs want to know when devices are created or removed,
+ and what /dev entry is associated with them.
+
+The constraints:
+ 1) No policy in the kernel!
+ 2) Follow standards (like the LSB)
+ 3) must be small so embedded devices will use it.
+
+
+So, how does devfs stack up to the above problems and constraints:
+ Problems:
+ 1) devfs only shows the dev entries for the devices in the system.
+ 2) devfs does not handle the need for dynamic major/minor numbers
+ 3) devfs does not provide a way to name devices in a persistent
+ fashion.
+ 4) devfs does provide a deamon that userspace programs can hook into
+ to listen to see what devices are being created or removed.
+ Constraints:
+ 1) devfs forces the devfs naming policy into the kernel. If you
+ don't like this naming scheme, tough.
+ 2) devfs does not follow the LSB device naming standard.
+ 3) devfs is small, and embedded devices use it. However it is
+ implemented in non-pagable memory.
+
+Oh yeah, and there are the insolvable race conditions with the devfs
+implementation in the kernel, but I'm not going to talk about them right
+now, sorry. See the linux-kernel archives if you care about them (and
+if you use devfs, you should care...)
+
+So devfs is 2 for 7, ignoring the kernel races.
+
+And now for udev:
+ Problems:
+ 1) using udev, the /dev tree only is populated for the devices that
+ are currently present in the system.
+ 2) udev does not care about the major/minor number schemes. If the
+ kernel tomorrow switches to randomly assign major and minor numbers
+ to different devices, it would work just fine (this is exactly
+ what I am proposing to do in 2.7...)
+ 3) This is the main reason udev is around. It provides the ability
+ to name devices in a persistent manner. More on that below.
+ 4) udev emits D-BUS messages so that any other userspace program
+ (like HAL) can listen to see what devices are created or removed.
+ It also allows userspace programs to query it's database to see
+ what devices are present and what they are currently named as
+ (providing a pointer into the sysfs tree for that specific device
+ node.)
+ Constraints:
+ 1) udev moves _all_ naming policies out of the kernel and into
+ userspace.
+ 2) udev defaults to using the LSB device naming standard. If users
+ want to deviate away from this standard (for example when naming
+ some devices in a persistent manner), it is easily possible to do
+ so.
+ 3) udev is small (49Kb binary) and is entirely in userspace, which
+ is swapable, and doesn't have to be running at all times.
+
+Nice, 7 out of 7 for udev. Makes you think the problems and constraints
+were picked by a udev developer, right? No, the problems and
+constraints are ones I've seen over the years and so udev, along with
+the kernel driver model and sysfs, were created to solve these real
+problems.
+
+So by just looking at the above descriptions, everyone should instantly
+realize that udev is far better than devfs and start helping out udev
+development, right? Oh, you want more info, ok...
+
+Back in May 2003 I released a very tiny version of udev that implemented
+everything that devfs currently does, in about 6Kb of userspace code:
+ http://marc.theaimsgroup.com/?l=linux-kernel&m=105003185331553
+
+Yes, that's right, 6Kb. So, you are asking, why are you still working
+on udev if it did everything devfs did back in May 2003? That's because
+just managing static device nodes based on what the kernel calls the
+devices is _not_ the primary goal of udev. It's just a tiny side affect
+of it's primary goal, the ability to never worry about major/minor
+number assignments and provide the ability to achieve persistent device
+names if wanted.
+
+All the people wanting to bring up the udev vs. devfs argument go back
+and read the previous paragraph. Yes, all Gentoo users who keep filling
+up my inbox with smoking emails, I mean you.
+
+So, how well does udev solve it's goals:
+ Prevent users from ever worrying about major/minor numbers
+ And here you were, not knowing you ever needed to worry about
+ major/minor numbers in the first place, right? Ah, I see you
+ haven't plugged in 2 USB printers and tried to figure out which
+ printer was which /dev entry? Or plugged in 4000 SCSI disks and
+ tried to figure out how to access that 3642nd disk and what it was
+ called in /dev. Or plugged in a USB camera and a USB flash drive
+ and then tried to download the pictures off of the flash drive by
+ accident?
+
+ As the above scenarios show, both desktop users and big iron users
+ both need to not worry about which device is assigned to what
+ major/minor device.
+
+ udev doesn't care what major/minor number is assigned to a device.
+ It merely takes the numbers that the kernel says it assigned to the
+ device and creates a device node based on it, which the user can
+ then use (if you don't understand the whole major/minor to device
+ node issue, or even what a device node is, trust me, you don't
+ really want to, go install udev and don't worry about it...) As
+ stated above, if the kernel decides to start randomly assigning
+ major numbers to all devices, then udev will still work just fine.
+
+ Provide a persistent device naming solution:
+ Lots of people want to assign a specific name that they can talk to
+ a device to, no matter where it is in the system, or what order they
+ plugged the device in. USB printers, SCSI disks, PCI sound cards,
+ Firewire disks, USB mice, and lots of other devices all need to be
+ assigned a name in a consistent manner (udev doesn't handle network
+ devices, naming them is already a solved solution, using nameif).
+ udev allows users to create simple rules to describe what device to
+ name. If users want to call a program running a large database
+ half-way around the world, asking it what to name this device, it
+ can. We don't put the naming database into the kernel (like other
+ Unix variants have), everything is in userspace, and easily
+ accessible. You can even run a perl script to name your device if
+ you are that crazy...
+
+ For more information on how to create udev rules to name devices,
+ please see the udev man page, and look at the example udev rules
+ that ship with the tarball.
+
+
+So, convinced already why you should use udev instead of devfs? No.
+Ok, fine, I'm not forcing you to abandon your bloated, stifling policy,
+nonextensible, end of life feature if you don't want to. But please
+don't bother me about it either, I don't care about devfs, only about
+udev.
+
+This is my last posting about this topic, all further emails sent to me
+about why devfs is wonderful, and why are you making fun of this
+wonderful, stable gift from the gods, will be gleefully ignored and
+possibly posted in a public place where others can see.
+
+thanks,
+
+greg k-h
~ianmdlvl / elogind.git / commitdiff