With the announcement of udev 018, Greg KH noted that at this time he is running with udev managing the /dev directory on his primary email and development server. He says, “this is a major milestone for udev and it proves that it is a viable solution,” going on to add, “udev development isn’t done, but for anyone who has not checked it out yet, I suggest you do so.“
Linux: “udev” 018, Howto
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
What is udev supposed to do? I don’t really care whether or not its a better solution then the old system… Just explain what it does (or will do)
Its a dynamic device management system that will add and remove device entries from /dev as those devices are added and removed from the computer system. It also allows persistent names for devices meaning that a name can always be known and does not have to be worked out by software or by hand. Its a critical part of the jigsaw that will form a full “device manager” solution for Linux, giving all the benefits of the Windows one.
Sounds like a step in the right direction.
Todays OS’s should have by default, but, that snidy comment aside, its this kind of work that is bringing Linux up to a state where it will be nicer for end users and computer users in general to use the system.
Show someone who has not used Linux a system that does’nt mount for them and watch the consternation and the eyes glaze over..
AdmV
I think you mix up two things there. What you mean would be automount which has been around for a while.
* What is the clear advantage that Udev has over Devfs.
* And can it detect hardware like kudzu or libdetect ?
The clear advantage is that it has an active maintainer. The old DevFS maintainer disappeared.
It uses hotplug for hardware detection. If it’s hotplug capable, udev/devfs will be able to add it to /dev on insertion.
I don’t want to sound anal, but there’s been a big discussion about this on here before. You should read it.
Here’s the link: http://www.osnews.com/story.php?news_id=5503
You’d prolly have to type half of the thread in here to answer your question, devfs-user.
“The clear advantage is that it has an active maintainer”
Like someone else couldn’t have picked up where the old maintainer left off. Sure I’ve read that the Linux devfs implementation was inferior to say FreeBSD’s, but it’s not like it couldn’t have been fixed.
“Like someone else couldn’t have picked up where the old maintainer left off. Sure I’ve read that the Linux devfs implementation was inferior to say FreeBSD’s, but it’s not like it couldn’t have been fixed.”
The advantage #1 is that Linux’s devfs has ‘unsolvable’ problems (race conditions), this is, *it couldn’t have been fixed* and it can’t be fixed.
The advantage #2 is that most of udev runs in *userland*, taking device naming policy away from the kernel, *and* making it easier to save persistent device names, etc.
“The advantage #1 is that Linux’s devfs has ‘unsolvable’ problems (race conditions), this is, *it couldn’t have been fixed* and it can’t be fixed.”
Bad implementation vs. good idea. There is nothing wrong with the design of devfs in general, only in Linux’s implementation.
“The advantage #2 is that most of udev runs in *userland*, taking device naming policy away from the kernel, *and* making it easier to save persistent device names, etc.”
Debatable. I am not convinced that this could not be achievable using a kernel based implementation.
> Debatable. I am not convinced that this could not be achievable using a kernel based implementation.
A kernel based impl could crash the whole kernel while I can kill(1) hotplug any time there is a infinite loop / crash / whatever. And /dev is still there if hotplug crashes, unlike a kernel based impl.
“A kernel based impl could crash the whole kernel while I can kill(1) hotplug any time there is a infinite loop / crash / whatever. And /dev is still there if hotplug crashes, unlike a kernel based impl.”
That was not part of your original argument, but you are at least starting to provide good reasons why a userspace solution is better.
There is more to it:
1. “bad implementation vs. bad idea”. but, if you join a bad existing implementation with lack of maintainership with really bad engineering of the implementation (if you want it to work, you must implement it from scratch again…)
2. kernelspace vs. userspace. it *is* achievable, but…
2a. you would have do re-engineer it, to avoid the existing problems.
2b. you would have to deal with security problems, stability problems, in the course of the maintenance.
basically, what I’m telling you is: as of today (unless someone magically appear with a new devfs implementation), udev is the only viable alternative to a static /dev, and more … as of 2.7.x, it will be the only one (in the beginning of the 2.7 series, Linus plans to randomize device numbers to kill static /dev…
“What is udev supposed to do? I don’t really care whether or not its a better solution then the old system… Just explain what it does (or will do)”
Well most of the things it does is in the background so you won’t really care about that. But for sys admins, it does two very important things.
1) If you currently go to /dev directory and do ls on the directory, you will get five million and one device listed. This is not normal. It should only show hardware it can find.(Honestly, I’m a little surprised that it took Linux until now to fix this problem.)
2) Well, since Linux is now “Enterprise Ready”, it also has to worry about mission critical computers which have thousands of devices attached to them. Even though it will now only show devices you have, doing ls might still return a thousand results, making it difficult to find the correct device. Udev also uses a nice directory tree to show everything (ex. /dev/network, /dev/drives, /dev/SCSI, etc.)
“you would have do re-engineer it, to avoid the existing problems.”
No more work than udev to be sure
At any rate, either one is better than the static /dev mess that Linux has had forever.
if we’re going to do it in user land why not just do it in Perl?
Seriously. /dev is just a bunch of stupid files pointing to specific kernel device numbers. Map those numbers to the device names in a flat file database, have something like SGIs fam or imon execute your perl script to create the device files when something trys to access them or maybe after loading a kernel module that implements that hardware functionality..
It can’t be that hard. And what’s wrong with the standard /dev directory being preconfigured with ALL the devices anyone would ever use? Sure its a mess, but at least we wouldn’t have to waste time reimplementing it.
personally i hate the /dev directory being overrun with device nodes that will never be attached to any hardware on any system i deal with. I think that any operating system which expects to be called “modern” should have a dynamically created list of devices availible to the system that is persistent in the naming/identifying of those devices between reboots and hotswaps of that hardware.
i really dont care if its a /dev replacement, or it /dev is left alone and a new folder /devices or /dev/devices or whatever is created for it. as long as the device names i am given for my several usb memory keys is consistent and not dependant upon the order in which i attach them to the system.
I’m sold. Where can I get the latest, complete entire set of scripts for my distro?
“Where can I get the latest, complete entire set of scripts for my distro?”
People could be more helpful if you mentioned what your distro is…
I’m running udev for my /dev under Fedora 1 and the 2.6 kernel. I’m doing this because I’m working on driver support for sysfs. My /dev has about 100 entries in it.
It is possible to run udev right now but I would only recommend it to experienced developers. I needed to use my rescue disk a lot to deal with various problems in converting. Any mistakes will make your system unbootable. Normal users should wait until this comes out in a distro.
The big advantage is that you can do an ls /dev and see what hardware is present on your system. This is much better than my old /dev which had about 10,000 entries.
Easiest distro to try this on is gentoo.
Here’s my /dev
adsp hda4 loop6 ram11 random stdin tty4
agpgart hda5 loop7 ram12 rtc stdout tty5
audio initctl md0 ram13 sda tty tty6
console input mem ram14 sda1 tty0 tty7
core kmem mixer ram15 sda2 tty1 tty8
dsp kmsg null ram2 sda3 tty10 tty9
fd log port ram3 sda4 tty11 ttyACM0
full loop0 psaux ram4 sda5 tty12 urandom
gpmctl loop1 ptmx ram5 sda6 tty13 watchdog
hda loop2 pts ram6 sda7 tty14 zero
hda1 loop3 ram0 ram7 shm tty15
hda2 loop4 ram1 ram8 snd tty2
hda3 loop5 ram10 ram9 stderr tty3
This file looks very complete.
http://kernel.org/pub/linux/utils/kernel/hotplug/udev-018.tar.gz
http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-…
OR
http://tinyurl.com/3dxrl
This pdf will provide most people with a satisfactory answer
as to why udev is most likely both a better idea and implementation than devfs. It’s a lttle long, but worth it.