The beginning of the end for devfs

[Posted September 24, 2003 by corbet]

One of the patches that will appear in 2.6.0-test6 is one marking the devfs subsystem as being obsolete. The patch from Christoph Hellwig reads:

Richard [Gooch] hasn't touched it for about a year and since then only bugfixes and my changes to the kernel interface went in. No one has stepped up to maintain it and with udev we have a proper replacement now.

Devfs was the subject of countless heated linux-kernel battles in the years leading up to its inclusion in 2.3. It made rather less of a spash afterwards; none of the major distributors have enabled devfs in their kernels, with the (arguable) exception of Gentoo. When a subsystem does not get used, and especially when its maintainer stops working on it, that subsystem's future tends to be dim. Such is the case with devfs. Christoph has said he will continue to fix a few problems, but will do no more with it. 2.6 may be the last major kernel series that includes the devfs subsystem.

The beginning of the end for devfs

Posted Sep 25, 2003 2:15 UTC (Thu) by jonabbey (guest, #2736) [Link] (5 responses)

Are there any good summaries of udev?

Coverage of udev

Posted Sep 25, 2003 2:59 UTC (Thu) by corbet (editor, #1) [Link] (1 responses)

Well, we've looked at it, here, and here, and, briefly, here.

Coverage of udev

Posted Sep 25, 2003 5:48 UTC (Thu) by jonabbey (guest, #2736) [Link]

Thanks Jonathan.. I rather imagine you would have covered it, I just didn't really know what it was enough to make an effort to look.

The beginning of the end for devfs

Posted Sep 25, 2003 3:38 UTC (Thu) by gregkh (subscriber, #8) [Link] (2 responses)

There is the OLS 2003 paper and the OLS 2003 talk that goes into some detail about the problem, and what udev can do.

And if that doesn't explain things well enough, feel free to ask questions on the linux-hotplug-devel mailing list.

The beginning of the end for devfs

Posted Sep 25, 2003 7:35 UTC (Thu) by ken (subscriber, #625) [Link] (1 responses)

When using devfs I can have an empty /dev as the kernel takes care of filling it in but unless we are going to start the udev instead of /sbin/init that is not going to work anymore.

So what would a minimal /dev look like when using udev ?

The beginning of the end for devfs

Posted Sep 25, 2003 23:48 UTC (Thu) by gregkh (subscriber, #8) [Link]

udev can start up before any devices are initialized, due to initramfs. So it will be able to populate an empty /dev from boot, just like devfs can.

I don't understand your question about /sbin/init.

The beginning of the end for devfs

Posted Sep 25, 2003 6:32 UTC (Thu) by Frej (guest, #4165) [Link] (2 responses)

Mandrake does enable it as default, not sure if they are a major dist though ;).

The beginning of the end for devfs

Posted Sep 25, 2003 8:17 UTC (Thu) by ppedroni (subscriber, #6592) [Link] (1 responses)

> Mandrake does enable it as default, not sure if they are a major dist
> though ;).

And it even works out mostly right. I never understood why everyone was so much against it.

The beginning of the end for devfs

Posted Sep 25, 2003 22:02 UTC (Thu) by rankincj (guest, #4865) [Link]

There were a number of long-standing security issues with the earlier implementations, IIRC. And I think that people also objected to having a device naming scheme within the kernel.

The beginning of the end for devfs

Posted Sep 25, 2003 12:32 UTC (Thu) by mennucc1 (guest, #14730) [Link]

I may be wrong, but it looks as if the debian-installer (the newer installer for the upcoming release Debian sarge) uses devfs: at least, the names that it gives to disks and partitions are those used by devfs.

The beginning of the end for devfs

Posted Sep 25, 2003 19:48 UTC (Thu) by ksmathers (guest, #2353) [Link]

Lindows also installs with devfs enabled by default (and symlinks in /dev to all of the old device names), at least in the most recent version.

The beginning of the end for devfs

Posted Oct 2, 2003 13:25 UTC (Thu) by koriordan (guest, #3490) [Link]

I find devfs on mandrake very handy. especially when you're debugging whether a device has been picked up and what /dev link it's been assigned, you can see very quickly, instead of having to navigate through 100s of phantom links.