What's to become of devfs? [LWN.net]

From a recent posting by Alexander Viro:

During the last couple of weeks I'd done a lot of digging in devfs-related code. Results are interesting, and not in a good sense

He continues with a long list of changes he would like to make to the devfs code; it's a massive set of cleanups which would, it is claimed, shrink the devfs code base considerably and make things work better. Comments were requested on the proposal; the few that came in were favorable.

The posting led to an entirely different sort of discussion, however. As Ted Ts'o asked, how many people are actually using devfs?

In any case, if there aren't all that many people using devfs, I can think of a really easy way in which we could simplify and clean up its API by slimming it down by 100%......

The question is worth asking. Despite the fact that devfs has been in the 2.4 kernel since it first shipped, very few distributions are turning it on for their customers. The devfs way of doing things has failed to take over the world.

And, perhaps more to the point, there is a new approach to dynamic device management that, while not yet actually implemented, is attracting interest. The combination of the /sbin/hotplug mechanism and the device model provides (or can provide) everything that is needed to create devfs-like filesystems in user space. The device model, via the sysfs (formerly driverfs) filesystem, provides a complete view of the state of the system, including all attached hardware. /sbin/hotplug gives user space the ability to know about (and react to) changes in the system state. Using that information, user-space code can populate a device directory hierarchy that implements just about any kind of policy that one could imagine.

All it takes is somebody to hack up the remaining pieces; a user-space devfs could easily be a reality in the 2.5 development series. And, since it lives in user space, there are no real issues with the feature freeze.

Of course, none of this points to a removal of devfs in this development series. Removal of features violates the feature freeze as surely as additions do. It is also standard practice to leave such features in place (though "deprecated") for one stable series to give users time to make the transition. So, even if the decision to remove devfs is made (and that certainly has not happened at this point), it will be around for a while.

to post comments

What's to become of devfs?

Posted Nov 14, 2002 6:18 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

The problem with devfs is that it hasn't got the support of the rest
of the system. We need something like a translucent (overlay) filesystem
so that devfs can be mounted over /dev --- so the dynamic entries can
be used, and the system will fall through to the static device nodes
thereunder. (And some provision as to be made so that the permissions
ownership and now any ACLs or EAs (extended attributes) can be made to
to "show through."

I think these system changes (planned for 2.8 now anyway) will do away
with devfsd --- which seems like a kludge like kerneld did.

devfs is a good idea. However, it's a BIG change and will have to be
adopted slowly, probably will need more support (such as this unionfs
feature) and the implementation probably does need to be cleaned up.

I think combining devfs's dynamic model with the massive naming and
organizational chanages (/dev/hda becomes /dev/discs/disc0/disc *and*
/dev/ide/host0/bus0/target0/lun0/disc) was a bad idea. It increases the
risk and aversion to adopting the new code as a standard.

We are seeking the "backwards" part of "backwards compatibility here.

What's to become of devfs?

Posted Nov 14, 2002 7:59 UTC (Thu) by eru (subscriber, #2753) [Link] (4 responses)

> Despite the fact that devfs has been in the 2.4 kernel since it first
> shipped, very few distributions are turning it on for their customers.

Mandrake Linux, a very popular distro, has had devfs activated
by default at least since version 8.2 (possibly earlier, but of
8.2 I'm quite sure since I use it). Thus this feature has a
non-trivial number of customers, even if it is not enabled in
most distros.

What's to become of devfs?

Posted Nov 14, 2002 11:44 UTC (Thu) by csawtell (guest, #986) [Link]

Gentoo uses it, so I use it. It works well. Please don't take it away.

What's to become of devfs?

Posted Nov 15, 2002 3:04 UTC (Fri) by melauer (guest, #2438) [Link] (2 responses)

Also, note that Debian is still on kernel 2.2, which means that devfs isn't even an option for that distro.

debian only has kernel 2.2.x ??

Posted Nov 16, 2002 13:17 UTC (Sat) by ernest (guest, #2355) [Link] (1 responses)

Hu ? I use Debian, it has all the kernels you wish.

You don't need to stick with the one that is installed first, Debian provides packages with the latest and greatest kernels. Including many packages that provided exotic patches not in the mainstream kernel.

and I'm talking stable, not necessarely unstable or testing.

debian only has kernel 2.2.x ??

Posted Nov 25, 2002 3:34 UTC (Mon) by elanthis (guest, #6227) [Link]

Yes, but they can't enable devfs by default, they have to use plain /dev. If all they shipped with 2.4, or at least if they shipped 2.4 as the default with no 2.2 install option, they could enable devfs by default.

What's to become of devfs?

Posted Nov 14, 2002 13:46 UTC (Thu) by brugolsky (guest, #28) [Link] (1 responses)

I think you missed the real point of Al Viro's work, which is that the cleanups that he is proposing would remove cruft from the drivers. In that sense, it is a worthwhile cleanup, even if devfs is not turned on by many of users, because it will make life easier on driver writers and maintainers. (Given, as you say, that devfs will live on for at least another stable iteration.)

Of course, Ted has a point; there are other things that might profit more from Al's chainsaw.

What's to become of devfs?

Posted Nov 21, 2002 16:10 UTC (Thu) by Baylink (guest, #755) [Link]

"Al's chainsaw".

Heh. :-)

What's to become of devfs?

Posted Nov 14, 2002 16:00 UTC (Thu) by a9db0 (subscriber, #2181) [Link] (1 responses)

Gentoo ships with devfs enabled, and in fact won't run without it in its standard config.

Gentoo may be considered a "minor" distribution, but its popularity is growing rapidly. Just browse through the comments in the current poll on slashdot.

What's to become of devfs?

Posted Nov 22, 2002 2:17 UTC (Fri) by yem (guest, #1138) [Link]

I recently switched to gentoo. As you say, the "standard config" specifies a devfs setup and all of the documentation assumes that you are using it.

Personally, I've had trouble with devfs in the past and I'm using gentoo without it. Creating the devices I need by hand was tedious..

I like the idea of having devfs with a fall through to traditional device files.

I have it switched on

Posted Nov 14, 2002 20:30 UTC (Thu) by ernest (guest, #2355) [Link]

devfs is beter.

I have to admit though, even after all this time, it still feels unconfortable to use.

too many cludges to keep the privilege info uptodate.
too many name changes.

I still have trouble find devices which had an obvious location before.

don't misunderstand me. something like devfs is the way to go. but we're still not there.

Ummm... devfs?

Posted Nov 17, 2002 4:51 UTC (Sun) by JLCdjinn (guest, #1905) [Link] (1 responses)

I almost got Gentoo installed on my shiny new Inspiron a couple weeks back (the only reason I failed was user error), and I plan to give it another go when I get a touch of spare time (given how much of it Gentoo takes to install) - I have the partition ready and waiting. One of the first weird things I noticed was this thing called devfs, which I hadn't heard mention of before. And here it pops up again, and people are now considering taking it out of the kernel.

Well, I'd like to ask what it is. I couldn't find documention on it at The Linux Documentation Project, and a search for 'devfs documentation' on Google returned only mailing lists and changelogs. What gives? What is devfs? What problem was devfs designed to solve, and what's wrong with devfs as a solution? Where can I find documentation about how to utilize devfs? I have to agree with AnswerGuy that /dev/ide/host0/bus0/target0/lun0/disc is rediculous. I was... intrigued the first time I saw that.

More information would be greatly appreciated, although as always I'm grateful to LWN for a good piece of news.

Ummm... devfs?

Posted Nov 18, 2002 22:29 UTC (Mon) by dododge (guest, #2870) [Link]

Look for just "devfs" with Google. The first item in the list is the FAQ from the devfs maintainer.

In brief: the "/dev" directory contains device files. Traditionally this is just a normal directory, and is preloaded with files for every device you might ever have connected. For example there might be a whole bunch of device files related to SCSI tape drives even though you have never had a tape drive (or SCSI bus, for that matter) attached to the machine.

devfs replaces this static directory with one generated by the kernel at runtime. Device files are created and removed on the fly when the associated driver is loaded and unloaded. Under devfs, you can get a quick view of attached devices and loaded drivers by simply looking at the contents of /dev.

devfs does shuffle some things around, though. The traditional /dev structure is almost entirely flat, while devfs makes extensive use of subdirectories (and in some cases quite deep subdirectories). Applications looking for certain device files might have to know about both the traditional and devfs locations for those files. Since not all applications actually do this, there's "devfsd", which is a daemon that can perform actions on device files. Probably the most common use for devfsd is to have it create symlinks from the "traditional" device locations to the equivalent "devfs" locations when the device comes up.

What's to become of devfs?

Posted Nov 21, 2002 6:40 UTC (Thu) by darthmdh (guest, #8032) [Link]

Pretty much everyone I know, myself included, use devfs exclusively (and have for years). It is very well documented both kernel and userspace sides and very easy to configure (if your distribution doesn't do it by default).
The argument that many distributions don't enable it by default - hence it is okay to remove it from the kernel - is very short-sighted, most I know of do (particularly on boot floppies where you don't have the space to waste with a traditional /dev). In any case, whether a distribution uses it or not by default is irrelevent, I don't know anyone who ever runs a stock distribution kernel.
Should there be a better way to do dynamic device management, bring it on. devfs has been the only option for years, hence why so many people use it and love it.

What's to become of devfs?

Posted Nov 21, 2002 11:47 UTC (Thu) by TheOneKEA (guest, #615) [Link]

I like devfs. It's a much cleaner way to talk to the devices. The namespace itself is a small problem, since I think it's too deep, but otherwise it'svery useful.

I hope devfs doesn't goaway entirely, but that its functionality gets merged with something else in the kernel (hotplug, driverfs, procfs, etc). I don't want to use static device nodes anymore.

Keep devfs!

Posted Nov 21, 2002 12:07 UTC (Thu) by job (guest, #670) [Link]

Noooooo! devfs is a saviour. People that use the backwards-compatible naming are really missing the best. Two examples: 1. Better organization. /dev/sound/dsp is better than /dev/dsp. 2. The IDE and SCSI naming are named after their actual address! Just like on Solaris. This means I can put new disks in the system without renaming the existing ones. This feature is worth a lot! I've used it exclusively since it was only a little patch.

What's to become of devfs?

Posted Nov 21, 2002 17:52 UTC (Thu) by MLKahnt (subscriber, #6642) [Link]

I roll my own kernels on Debian, and started building devfs with kernel 2.4.5, although it wasn't until 2.4.9 that I got those kernels to successfully boot - I didn't read closely enough that I'd also need devfsd (oops!) Since then, I've used it and found it wonderful as I tried to get a couple ornery extensions working (tv tuner, usb camera, usb printer) - if I couldn't find the device, obviously something wasn't *quite* right. Traditional /dev wouldn't have given me that opportunity, and I find that I can check it with fewer keystrokes than I can /proc. This *trimmed down* /dev actually means that you can find things - and on a large xterm, can see all of /dev itself on the screen at once. The replacement suggested might handle this just as well or better, but simply put, it is a fine part of the system and a great benefit from my experience, and I suspect that it is more useful for most users than the kernel http server.