A recent posting to the lkml suggested that the udev project has unfairly hijacked the devfs project, leading into yet another lengthy discussion comparing udev to devfs, and questioning why the latter has been deprecated. Linux devfs was written by Richard Gooch and merged into the 2.3.46 kernel in February of 2000.
Linux: Debating devfs and udev
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I have heard that they want to drop devfs because thier coder have disappear. Anyway, udev looks nice, I’ll put it into my 2.6.0 while next compilation.
“I have heard that they want to drop devfs because thier coder have disappear. Anyway, udev looks nice, I’ll put it into my 2.6.0 while next compilation.”
Well, if you do so, I think you are going to regret it. The reason why devfs is still in 2.6 is because it is proven, it is production ready, it is faster, and it has much better support. Even for regular desktop use, I wouldn’t even think of trying out udev until people tell me it is ready for production use. Using it now won’t do me or you any good.
There’s udev, devfs, sysfs, and hal. Now, I understand how these are applied: sysfs => [devfs|udev] => hal. But would someone be nice and explain to me what each part does? I’m not really into the matter (yet), but I feel there’s a lot of duplication?
Also, who actually uses these things? Should I ? Are there any fancy configuration tools to use with these packages?
It is very clearly explained here http://www.kroah.com/linux/talks/ols_2003_udev_talk/
even if you know just the basics of unix/linux.
Check this out http://www.kroah.com/linux/talks/ols_2003_udev_talk/mgp00011.html
Looks as if udev can name its devices just as devfs does.
Personally as a device driver writer, I never liked devfs, especially when it came time to write the userspace software, but if udev is able to stick to LSB names I might be sold.
It seems to me like all of the issues that the udev folks have with devfs could be solved *in* devfs, without needing a separate (from the kernel) implementation. I am still reading up on both sides of the issue, and I do have a bias here, so understand that this is only my opinion on the matter.
FreeBSD is using devfs and life has been pretty sweet since they droppped the countless thousands of static /dev entries. I guess I just have issues with a monolithic kernel dumping things like this into userspace, silly as that may sound. Not any sillier than a few of their reasons for disliking devfs though: “requires lots of system configuration changes” puhlease.
Yet another important thread on LKML that got turned into name-calling and flaming.
From what I understood, it seems that the original devfs coder left because he was being flamed (by Viro mainly) because of bad code. And now they have a problem — no maintainer so they need to write a new system to replace the old one.
Kindergarten anyone?
Still. This is nothing compared to the flames you see on OpenBSD-related mailing lists. No wonder people hate them.
The Linux kernel is the most important software project in the world. I wish the developers would grow up already.
You can tell that the person who made the complaint probably never even looked up the devfs code. Did you see the crap he was spewing? Udev is slow because it’s in userspace???
Anyway, the gentoo folks have gotten udev working. If you use Gentoo, check the Documentation and Tricks forums and the gentoo bugzilla for a useful howto. An official documentation will be out any time soon.
I’ve had no problems with udev.
Yes udev does work in Gentoo, however from what I read it takes a little bit of work to get it up and running. It’s not like devfs where you check two options and your set.
actually.. devfs contains an insolvable race condition.. note… i did say insolvable.. it is impossible to solve..
devfs is crap code anyways..
userspace is the proper place to implement what you wanted from devfs
“actually.. devfs contains an insolvable race condition.. note… i did say insolvable.. it is impossible to solve.. devfs is crap code anyways.. ”
Yet another guy who cannot tell the difference between bad theories and bad implementations. It works fine on FreeBSD, and I’ve read nothing about “insolvable” race conditions there. Devfs is in my mind a better solution to this problem than this braindead udev idea.
“userspace is the proper place to implement what you wanted from devfs”
Why is it that for all of the great things in Linux the kernel, there seems to be a userspace daemon required to deal with it. It’s madness. Why not just just take the plunge and turn Linux into the Hurd? Your arguments would make more sense if the most of the kernel was designed to be in userspace from the begining.
userspace is the proper place to implement what you wanted from devfs
I’ve heard many people say this, but not a single one of them has ever backed this claim up with an argument. Why is it better handled in userspace? Since when was exporting kernel interfaces a userspace function?
Hi
1) Devfs implementation is different between linux and freebsd. While the idea might be good the devfs implementation in linux is unmaintained and has race conditions
2) Devfs is not going to be pulled off and you are free to use either of them
3) The email calling greg a terrorist is pure hogwash. You cant expect anything but flamewars.
4) If you are skilled enough to maintain devfs you are free to take it up
5) Viro knows what he is talking about
Hardware management cannot entirely be in userspace or kernel space. You need interfaces in the kernel and userlevel tools to manage them
“Devfs is not going to be pulled off and you are free to use either of them”
Last I checked, Linux devfs was deprecated, meaning that they plan on removing it. I personally would have no problem here if they were going to keep it longer than it takes them to make udev stable.
Hi
Andrew morton said that devfs would be retained till udev is proven to be a mature solution so you dont have to worry about that.
You might be intersted in reading this presentation
http://www.kroah.com/linux/talks/ols_2003_udev_talk/mgp00005.html
“Last I checked, Linux devfs was deprecated, meaning that they plan on removing it.”
Deprecated; yes. Deprecated does not mean “scheduled for removal” in my dictionary nor have i readed it will be removed.
Paul Dickson said in above thread:
“Devfs is deprecated. This means it’s still available but you should consider moving to other options when available. Obsolete means it shouldn’t be used. Some 2.6 docs have confused these two terms WRT devfs.
[…]
Since 2.6.0 shipped with devfs deprecated, it’s conceivable,
although unlikely, that devfs could be removed once a udev-like project is fully functional.”
explain how policy can not solve a race condition?
and what kind of race condition are we talking about here? is DevFS trying to access files? well then why is the file manager not dealing with that?
explain to me at what level the race condition occurs, then explain to me the reasons it is “insolvable”.
Hi
Greg K-H is the guy maintaining udev. He has talked about it in lkml You should either search the archives and refer to the udev faq
http://mirrors.sunsite.dk/kernel/utils/kernel/hotplug/udev-FAQ
udev is much better and cooler. Say, you have 2 USB printers. A epson and a HP. You plug in the epson. devfs will name it /dev/usb0 (or whatever). After that, you plug in the HP and it will be called /dev/usb1. If you remove them, and you plug in the HP one first this time, it will be called /dev/usb0. This is, the HP was called one time /dev/usb1 and the second time /dev/usb0. This is because devfs lives in the kernel and there NO WAY that devfs can be *that* smart.
udev would do:
You plug in the epson first. It calls it /dev/usb0 (the fun thing is that it could look at sysfs and call it /dev/epsonprinter, for example). you plug in the HP, its called /dev/usb1. You un plug them, and you plug in the HP this time first. udev CAN do: “mmm, this usb printer which is connected in the first usb port with a serial numer xxxx, from vendor xxxxx was plugged in before in the second usb port and I called it /dev/usb1. I think it’d be nice to call /dev/usb1 instead of /dev/usb0, the user who relied in /dev/usb1 being the HP will like it”
Now, imagine thousand of disks with devfs. Compare it with udev. Scary.
What is better: after rebooting, udev *still* knows what it did with devices. How in hell is devfs going to face with that, huh?
In short: udev can decide whatever it wants with the device names, and unlike devfs, udev can look to serial numbers, vendors, etc; through sysfs. udev is also _small_ (a few KB IIRC). It’s _fast_ (you can put /dev in ramfs if you like). It is much more resource frienrdly, since devfs _lives in the kernel_ and it eats memory from the kernel adress space, which, as you know, it’s limited. This is a *problem* when you have thousand of ie: thousand of disks lying around, and it’s devfs strcutures would be keept in kernel space, eating mem for buffers, etc. udev can be swapped out.
Also, udev can notify userspace of events. For example: when it creates a node, it can tell D-BUS (in fact, it’s already sending messages to d-BUS in the current version IIRC) “A new device has been found, I’ve put it at /dev/foobar”. In te future, when gnome/kde people develop the neccesary tools, you’ll have something like “Your xxx camera has been found, do you want to download the fotos on it?”.
From what you’re saying it really sounds like udev is the way to go. To me it sounds like udev is a natural step in the process of ‘desktopifying’ GNU/Linux.
I can’t wait to see this nifty features of udev and D-BUS/HAL in action.
I am totally unconvinced that devfs cannot be made to do all of the things that you say udev can do. Surely some of the mightly Linux maintainers can implement such simple ideas in code?
I’m not trolling, I am dead serious. They can’t be nearly as dumb as half of us here.
So, *how* are you going to implement similar features with devfs?
How will you save the device namig policy state you’ve created across reboots? There’s only one way of doing that: Storing it in a file in userspace.
Kernel hackers are very smart and they’ve faced the devfs problems. That’s why udev exists. Why it’s so hard to understand that udev is *good*?
> Also, udev can notify userspace of events
bear in mind that i don’t know what i’m talking about and i don’t care either way about who wins the argument, but:
surely devfs can do this with the EXECUTE keyword in your devfs.conf. although i’ve never seen this used for anything more exciting that setting up some symlinks, or enabling pcmcia hotpluggery.
in fact, now i think about it, this could probably be used to do your /dev/epsonprinter stuff, capturing the REGISTER event of a usb printer:
REGISTER (usb/lp.*|printers/.*) EXECUTE /foo/bar
where /foo/bar would find out some stuff about the printer and set up a symlink. this doesn’t sound as elegant as the udev system you descrieb, but it does imply that devfs can protrude into userspace.
again, i don’t claim to have done or be able to do this, and if anybody knows that i’m wrong then it would be interesting to hear why.
No, you can’t.
DevFS merely assigns each device a sequential address based on it’s ‘type.’ You plug in a USB thing, it is at /dev/usb0 or /dev/usb1.
You can’t change this, because it has to live in kernel space. You do not have a large amount of memory in kernel space. Kernel space is only there for really ultra-low end stuff.
With kernel space, you also can not store any files in a persistant way. What your thinking of with your devfs.conf file is devfsd, not devfs.
But just for fun, let’s play with your idea.
You plug in USB printer Epson on /dev/usb1. DevFSd has now tossed a event and run /usr/sbin/get_printer.sh. How does it parse through to find out what /dev symlink to make? DevFS does not provide any extra information, it just says “hey, I have a USB device over here.” You could read /sys, but that’s what udev is doing, and for some reason you think this is the wrong answer. So, what do we do? How do you get the needed information for that device. Hell, how do you remove the original /dev/ entry that is, now, unneeded because you have the device’s ‘real’ entry?
Better yet, we remove something, and add a new one. now /dev/usb1 is a different Epson. Why? Because devfs is a kernelspace filesystem that can not make a note of things like this. It has a very, very small amount of memory to work with, and no access to a file because only userspace gets to touch files.
But let’s say it makes a symlink to /dev/epson##, just to make it easy.
So KDE is set to print to /dev/epson0 because that’s where the printer is. You’ve removed the Epson and replaced it with the new one. The only thing that knows about this is DevFSd. Your script is still making a /dev/epson0, but it’s the same for both unless they both are in the machine at the same time, and even then the numbering is the devil’s work.
This is just for a printer. Imagine having 20 different USB mice, and each needing a different configuration.
What about USB keyboards? USB cameras? USB disks?
DevFS makes life very difficult.
These nice theories about how devfs could be made as cool as udev or even cooler are — sorry — totally worthless, unless there is someone who does the actual coding work. And this is exactly devfs’ problem. Nobody is working on it. But there are developers working on udev. (Note that these same developers don’t work on enhancing devfs because they think it has a fundamendaly broken design)
first, i didn’t say udev is the wrong answer. i made it clear before that i didn’t really want to get drawn into the argument.
all i was saying is that it seemed to me, a casual observer, that devfs could do some of the things mentioned in a previous post. if you’re saying that udev does it better, then great! i don’t really care. most of my devices work fine, but if it just happens that future versions of gnome and kde make it even easier for me, then i’ll be happy. i won’t care about the underlying technology. so just to reiterate: i am satisfied with whatever system gets the job done, and i don’t have any emotional attachment to either.
but back to the point. the difference between devfs and devfsd… i can’t see how that’s relevant. but you say that my example about devfs is just doing what udev is doing. isn’t the point of these arguments that devfs _can’t_ do what udev does? i don’t see how, once devfsd is involved, one can’t do exactly the same kind of thing udev does. it also seems to me that the counter-examples you give are just the result of a crap userspace script, as opposed to a restriction placed on the system by devfs.
i suppose my point is this: why can’t we just have really cool userspace tools that hook into devfsd?
(and i guess that the answer to this is that nobody is writing code for devfs anymore
sorry if it seems like i’m continuing a pointless argument. i suspect there’s actually no argument at all, and udev will be great. i just wasn’t convinced by your examples (possibly because of my lack of knowledge).
Don’t mind me, I was just waking up and cranky.
isn’t the point of these arguments that devfs _can’t_ do what udev does? i don’t see how, once devfsd is involved, one can’t do exactly the same kind of thing udev does.
For DevFS to do what you need, you’d need userspace stuff and a grand deal of rewriting the hooks it provides. DevFS creates nodes instantly, without the ability to do any fine tuning. It’s just daftly making your /dev/ entries, and you can’t change that without work on the drivers, and even then you can’t control it without hacking the kernel to change defaults.
Not fun.
DevFSD does some slight symlinking after devfs makes things available without being able to know if something new is there or not, but there isn’t any way to get any real information. It’s for mounting USB drives, setting permissions and logging additional things. Maybe you could pull some from somewhere else, but that’s what udev is doing in addition to depricating devfs. What people keep asking for, ‘keep devfs just make it better,’ is being done by removing everything about it thats made useless by the fix.
It just so happens that that’s everything.
it also seems to me that the counter-examples you give are just the result of a crap userspace script, as opposed to a restriction placed on the system by devfs.
Have you tried to read information from devfs to determine what a device is?
DevFSd can’t do anything really elaborate. Just toss a notice to a script and say “hey, lookie, device.” Like I said, you plug a printer in, and you get a symlink to /dev/printer##. You can’t do any real checking on what exactly the printer is, and if you want to code any apps for GNOME/ROX/KDE/XFCE, your going to use the base /dev entries because you know what’s what will be there.
Right now, you can have something like /dev/printers/printer##, and it’ll have all your printers there. This isn’t really what happens, but it works for a hypothetical.
When you plug the printer in, you get the next lowest printer##. You plug your HP in, you get printer0, plug your epson in, get printer1, take the first one out and plug a new one in and get printer2. Reboot. Now you have the former printer2 as printer0, and the epson stays at printer1. And the user is just sitting there going “gah, why didn’t I get the iBook.”
Or maybe that’s just me.
How can you configure for that? DevFS doesn’t really give you any information to tell what is what. DevFSD isn’t called until after the fact and even then it can’t really do anything because it doesn’t have any real information to use.
Imagine, instead, a /dev/printers, which has each printer listed as /dev/printers/HP0 for your first HP printer, /dev/printers/Epson0 for your first epson, and /dev/printers/Epson1 for another epson. Regardless of what you plug in, they will always have those names, and always be able to pull the configuration stuff they need correctly. That’s what udev lets you do, because it’s not just dealing with just device nodes, but rather with all sorts of data it can pull.
Or if you just say “eh, I’m tired and configuration files make me angry. SYSOP SMASH!” you just let it create you a /dev/printers/printer0, /dev/printers/printer1, and /dev/printers/printer2 which are the same across reboots, regardless of what you plug into the USB ports. The HP always gets /dev/printers/printer0, the first epson /dev/printers/printer1, and the second epson /dev/printers/printer2. That’s udev’s default behavior.
To get devfs to do what udev is doing, you’d need to combine it with devfsd and some other parts. Now you have a system that works partly in kernel, partly in userland. Everyone using DevFS complains because you up and change everything, you still have to deal with the bugs in DevFS, no one’s happy, one for the SCSI_EMULATION people posts a flame in confusion, and it’ll require a massive gutting of the code anyway.
The way udev works is by reading sysfs and creating/removing dev entires when it gets a notice from /sbin/hotplug something has changed. This is possible because sysfs is kind of a merge of procfs and devfs. Only… not. But it works for explaining this away.
Honestly, the only way to really appreciate why this is the way to go is to research. A good half-hour with google will pull you enough information to see why everyone coding wants to go this way.
Thank you very much for your reasoned and well written explaination.
smeat!
I think a lot of people have the wrong idea about udev. IMHO, you should see udev as a rewrite, based on the lessons (and mistakes) learned from devfs.
* udev reuses a lot of the existing infrastructure already available in the kernel. Sysfs/kobject was necessary for power management, and hotplug existed already too. So udev is a reduction of kernel code in a lot of ways, that’s always good.
* udev runs in userspace – this means more robust, easier debugging, more facilities available to udev, etc. A flaw in kernel code can be catastrophic, so it’s smart if you’re able to provide features without having to resort to adding more kernel code.
* other facilities in the kernel are probably also going to move to userspace. Things like the in-kernel dhcp client (necessary for bootstrapping network clients) are probably going to be replaced with similar userspace code that will probably embedded in initramfs.
* devfs put the naming policy in the kernel – not a good idea. Naming in the end is a matter of taste, and to just stuff this in unpageable kernel code, hardcoded, was probably a bad idea. With udev you can have any naming policy you want, LSB, DEVFS, your distro’s, your own, anything.
* udev probably gives you more flexibility. Since it’s in userspace, someone might come up with a modified or completely different version with differen features. I’m sure people will be a lot more confortable hacking up udev than devfs.
* why not change devfs to do what udev does? Well, when devfs arrived, things like sysfs didn’t exist yet. It’s good to reevaluate current practices in the face of changing circomstances: if devfs would have been written when those facilities were already available, i’m positive devfs would’ve looked a lot more like udev. I think it’s a tremendous strength of Linux and its developers, that they’re not afraid to ask themselves the question: “Does this still make sense?”. A bad decision, or a decision that was originally good and now bad, does not need to be in Linux forever.
Personally I hope that by moving a lot of the things to userspace (initramfs) they’ll be able to make the kernel slimmer, more flexible, and more powerful. Does that mean everything should be moved to userspace? ofcourse not. In some cases where the interfaces to userspace would be too volatile, or where performance would be way better in kernel space (like the TUX in-kernel webserver before they made the kernel so good that a userspace httpd would have the same performance) it makes sense to just put it in the kernel.
IMHO, the kernel devs are not stupid. They had a great prototype with devfs, and I’m sure they’re very aware of its strengths and weaknesses. I’m sure that udev will take all that into account.
“IMHO, the kernel devs are not stupid”
I certainly do not think that the Linux kernel developers are stupid. I do however believe that they do not always think things through as well as they could (the in-kernel web server comes to mind).
I do like devfs better than udev. Unlike TUX, I believe that this sort of thing should be in the kernel and not in userspace. The Linux devfs may well have sucked, but that would be a problem of implementation, not design. I firmly believe that they could have fixed it, and made it do everything that they are redoing in udev.
At any rate, Linux is a constantly evolving system, and if this turns out to be as dumb as I think it is (like TUX) then there’s a good possibility that it’ll go away in time (like TUX
. I would just like to reiterate that devfs works wonderfully in FreeBSD, and I can see no reason why it could not in Linux.
I think the fact that there was a TUX, drove them to make the changes necessary to have equal performance in userspace httpd’s. It gave them something to aim for as it where. A bit like the netcraft “study” focused the efforts on the network subsystem. But who knows, maybe they would’ve also arrived to the same result without TUX.
As for the devfs thing, it’s pretty much established that the current implementation is broken, according to people who know better than me. The question becomes, when it’s established you have to rewrite it, how do you go about doing it?
Personally, I prefer a userspace solution because that gives the greatest flexibility and fewer problems. Also I’ve always considered hardcoding the naming policy like that a bit boneheaded (for the record, I’m ok with the names used in devfs).
The only feature you don’t get with udev is the “load modules when you access the device node”-thing. But even taking this into consideration, I personally still prefer udev.
What exactly do you have or need in, let’s say FreeBSD devfs, that you don’t have with udev? And why would you need it as a kernel filesystem?
“Also I’ve always considered hardcoding the naming policy like that a bit boneheaded”
Okay, sometimes I can be slow, but I am curious, why does a devfs implementation *need* to have a hardcoded naming policy? I can’t see any reason why… why can’t it do this like udev does?