chiark / gitweb /
fix typo in man page
[elogind.git] / docs / udev_vs_devfs
1                 udev and devfs - The final word
2
3                         December 30, 2003
4                         Greg Kroah-Hartman
5                         <greg@kroah.com>
6
7
8 Executive summary for those too lazy to read this whole thing:
9         I don't care about devfs, and I don't want to talk about it at
10         all anymore.  If you love devfs, fine, I'm not trying to tell
11         anyone what to do.  But you really should be looking into using
12         udev instead.  All further email messages sent to me about devfs
13         will be gladly ignored.
14
15
16 First off, some background.  For a description of udev, and what its
17 original design goals were, please see the OLS 2003 paper on udev,
18 available at:
19         <http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf>
20 and the slides for the talk, available at:
21         <http://www.kroah.com/linux/talks/ols_2003_udev_talk/>
22 The OLS paper can also be found in the docs/ directory of the udev
23 tarball, available on kernel.org in the /pub/linux/utils/kernel/hotplug/
24 directory.
25
26 In that OLS paper, I described the current situation of a static /dev
27 and the current problems that a number of people have with it.  I also
28 detailed how devfs tries to solve a number of these problems.  In
29 hindsight, I should have never mentioned the word "devfs" when talking
30 about udev.  I did so only because it seemed like a good place to start
31 with.  Most people understood what devfs is, and what it does.  To
32 compare udev against it, showing how udev was more powerful, and a more
33 complete solution to the problems people were having, seemed like a
34 natural comparison to me.
35
36 But no more.  I hereby never want to compare devfs and udev again.  With
37 the exception of this message...
38
39 The Problems:
40  1) A static /dev is unwieldy and big.  It would be nice to only show
41     the /dev entries for the devices we actually have running in the
42     system.
43  2) We are (well, were) running out of major and minor numbers for
44     devices.
45  3) Users want a way to name devices in a persistent fashion (i.e. "This
46     disk here, must _always_ be called "boot_disk" no matter where in
47     the scsi tree I put it", or "This USB camera must always be called
48     "camera" no matter if I have other USB scsi devices plugged in or
49     not.")
50  4) Userspace programs want to know when devices are created or removed,
51     and what /dev entry is associated with them.
52
53 The constraints:
54  1) No policy in the kernel!
55  2) Follow standards (like the LSB)
56  3) must be small so embedded devices will use it.
57
58
59 So, how does devfs stack up to the above problems and constraints:
60   Problems:
61     1) devfs only shows the dev entries for the devices in the system.
62     2) devfs does not handle the need for dynamic major/minor numbers
63     3) devfs does not provide a way to name devices in a persistent
64        fashion.
65     4) devfs does provide a deamon that userspace programs can hook into
66        to listen to see what devices are being created or removed.
67   Constraints:
68     1) devfs forces the devfs naming policy into the kernel.  If you
69        don't like this naming scheme, tough.
70     2) devfs does not follow the LSB device naming standard.
71     3) devfs is small, and embedded devices use it.  However it is
72        implemented in non-pagable memory.
73
74 Oh yeah, and there are the insolvable race conditions with the devfs
75 implementation in the kernel, but I'm not going to talk about them right
76 now, sorry.  See the linux-kernel archives if you care about them (and
77 if you use devfs, you should care...)
78
79 So devfs is 2 for 7, ignoring the kernel races.
80
81 And now for udev:
82   Problems:
83     1) using udev, the /dev tree only is populated for the devices that
84        are currently present in the system.
85     2) udev does not care about the major/minor number schemes.  If the
86        kernel tomorrow switches to randomly assign major and minor numbers
87        to different devices, it would work just fine (this is exactly
88        what I am proposing to do in 2.7...)
89     3) This is the main reason udev is around.  It provides the ability
90        to name devices in a persistent manner.  More on that below.
91     4) udev emits D-BUS messages so that any other userspace program
92        (like HAL) can listen to see what devices are created or removed.
93        It also allows userspace programs to query its database to see
94        what devices are present and what they are currently named as
95        (providing a pointer into the sysfs tree for that specific device
96        node.)
97   Constraints:
98     1) udev moves _all_ naming policies out of the kernel and into
99        userspace.
100     2) udev defaults to using the LSB device naming standard.  If users
101        want to deviate away from this standard (for example when naming
102        some devices in a persistent manner), it is easily possible to do
103        so.
104     3) udev is small (49Kb binary) and is entirely in userspace, which
105        is swapable, and doesn't have to be running at all times.
106
107 Nice, 7 out of 7 for udev.  Makes you think the problems and constraints
108 were picked by a udev developer, right?  No, the problems and
109 constraints are ones I've seen over the years and so udev, along with
110 the kernel driver model and sysfs, were created to solve these real
111 problems.  I also have had the luxury to see the problems that the
112 current devfs implementation has, and have taken the time to work out
113 something that does not have those same problems.
114
115 So by just looking at the above descriptions, everyone should instantly
116 realize that udev is far better than devfs and start helping out udev
117 development, right?  Oh, you want more info, ok...
118
119 Back in May 2003 I released a very tiny version of udev that implemented
120 everything that devfs currently does, in about 6Kb of userspace code:
121         http://marc.theaimsgroup.com/?l=linux-kernel&m=105003185331553
122
123 Yes, that's right, 6Kb.  So, you are asking, why are you still working
124 on udev if it did everything devfs did back in May 2003?  That's because
125 just managing static device nodes based on what the kernel calls the
126 devices is _not_ the primary goal of udev.  It's just a tiny side effect
127 of its primary goal, the ability to never worry about major/minor
128 number assignments and provide the ability to achieve persistent device
129 names if wanted.
130
131 All the people wanting to bring up the udev vs. devfs argument go back
132 and read the previous paragraph.  Yes, all Gentoo users who keep filling
133 up my inbox with smoking emails, I mean you.
134
135 So, how well does udev solve its goals:
136   Prevent users from ever worrying about major/minor numbers
137     And here you were, not knowing you ever needed to worry about
138     major/minor numbers in the first place, right?  Ah, I see you
139     haven't plugged in 2 USB printers and tried to figure out which
140     printer was which /dev entry?  Or plugged in 4000 SCSI disks and
141     tried to figure out how to access that 3642nd disk and what it was
142     called in /dev.  Or plugged in a USB camera and a USB flash drive
143     and then tried to download the pictures off of the flash drive by
144     accident?
145
146     As the above scenarios show, both desktop users and big iron users
147     both need to not worry about which device is assigned to what
148     major/minor device.
149    
150     udev doesn't care what major/minor number is assigned to a device.
151     It merely takes the numbers that the kernel says it assigned to the
152     device and creates a device node based on it, which the user can
153     then use (if you don't understand the whole major/minor to device
154     node issue, or even what a device node is, trust me, you don't
155     really want to, go install udev and don't worry about it...)  As
156     stated above, if the kernel decides to start randomly assigning
157     major numbers to all devices, then udev will still work just fine.
158
159   Provide a persistent device naming solution:
160     Lots of people want to assign a specific name that they can talk to
161     a device to, no matter where it is in the system, or what order they
162     plugged the device in.  USB printers, SCSI disks, PCI sound cards,
163     Firewire disks, USB mice, and lots of other devices all need to be
164     assigned a name in a consistent manner (udev doesn't handle network
165     devices, naming them is already a solved solution, using nameif).
166     udev allows users to create simple rules to describe what device to
167     name.  If users want to call a program running a large database
168     half-way around the world, asking it what to name this device, it
169     can.  We don't put the naming database into the kernel (like other
170     Unix variants have), everything is in userspace, and easily
171     accessible.  You can even run a perl script to name your device if
172     you are that crazy...
173
174     For more information on how to create udev rules to name devices,
175     please see the udev man page, and look at the example udev rules
176     that ship with the tarball.
177  
178
179 So, convinced already why you should use udev instead of devfs?  No.
180 Ok, fine, I'm not forcing you to abandon your bloated, stifling policy,
181 nonextensible, end of life feature if you don't want to.  But please
182 don't bother me about it either, I don't care about devfs, only about
183 udev.
184
185 This is my last posting about this topic, all further emails sent to me
186 about why devfs is wonderful, and why are you making fun of this
187 wonderful, stable gift from the gods, will be gleefully ignored and
188 possibly posted in a public place where others can see.
189
190 thanks,
191
192 greg k-h