1 udev and devfs - The final word 2 3 December 30, 2003 4 Greg Kroah-Hartman 5 <greg@kroah.com> 6 7 8Executive 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 16First off, some background. For a description of udev, and what its 17original design goals were, please see the OLS 2003 paper on udev, 18available at: 19 <http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf> 20and the slides for the talk, available at: 21 <http://www.kroah.com/linux/talks/ols_2003_udev_talk/> 22The OLS paper can also be found in the docs/ directory of the udev 23tarball, available on kernel.org in the /pub/linux/utils/kernel/hotplug/ 24directory. 25 26In that OLS paper, I described the current situation of a static /dev 27and the current problems that a number of people have with it. I also 28detailed how devfs tries to solve a number of these problems. In 29hindsight, I should have never mentioned the word "devfs" when talking 30about udev. I did so only because it seemed like a good place to start 31with. Most people understood what devfs is, and what it does. To 32compare udev against it, showing how udev was more powerful, and a more 33complete solution to the problems people were having, seemed like a 34natural comparison to me. 35 36But no more. I hereby never want to compare devfs and udev again. With 37the exception of this message... 38 39The 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 53The 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 59So, 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 74Oh yeah, and there are the insolvable race conditions with the devfs 75implementation in the kernel, but I'm not going to talk about them right 76now, sorry. See the linux-kernel archives if you care about them (and 77if you use devfs, you should care...) 78 79So devfs is 2 for 7, ignoring the kernel races. 80 81And 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 and is entirely in userspace, which 105 is swapable, and doesn't have to be running at all times. 106 107Nice, 7 out of 7 for udev. Makes you think the problems and constraints 108were picked by a udev developer, right? No, the problems and 109constraints are ones I've seen over the years and so udev, along with 110the kernel driver model and sysfs, were created to solve these real 111problems. I also have had the luxury to see the problems that the 112current devfs implementation has, and have taken the time to work out 113something that does not have those same problems. 114 115So by just looking at the above descriptions, everyone should instantly 116realize that udev is far better than devfs and start helping out udev 117development, right? Oh, you want more info, ok... 118 119Back in May 2003 I released a very tiny version of udev that implemented 120everything that devfs currently does, in about 6Kb of userspace code: 121 http://marc.theaimsgroup.com/?l=linux-kernel&m=105003185331553 122 123Yes, that's right, 6Kb. So, you are asking, why are you still working 124on udev if it did everything devfs did back in May 2003? That's because 125just managing static device nodes based on what the kernel calls the 126devices is _not_ the primary goal of udev. It's just a tiny side effect 127of its primary goal, the ability to never worry about major/minor 128number assignments and provide the ability to achieve persistent device 129names if wanted. 130 131All the people wanting to bring up the udev vs. devfs argument go back 132and read the previous paragraph. Yes, all Gentoo users who keep filling 133up my inbox with smoking emails, I mean you. 134 135So, 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 179So, convinced already why you should use udev instead of devfs? No. 180Ok, fine, I'm not forcing you to abandon your bloated, stifling policy, 181nonextensible, end of life feature if you don't want to. But please 182don't bother me about it either, I don't care about devfs, only about 183udev. 184 185This is my last posting about this topic, all further emails sent to me 186about why devfs is wonderful, and why are you making fun of this 187wonderful, stable gift from the gods, will be gleefully ignored and 188possibly posted in a public place where others can see. 189 190thanks, 191 192greg k-h 193