[PATCH] added udev vs devfs supid document to the tree.

1 files changed, 190 insertions, 0 deletions

diff --git a/docs/udev_vs_devfs b/docs/udev_vs_devfs
new file mode 100644
index 0000000000..5a46231c1f
--- /dev/null
+++ b/docs/udev_vs_devfs
@@ -0,0 +1,190 @@
+		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