What's to become of devfs?
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?
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.
Posted Nov 14, 2002 6:18 UTC (Thu)
by AnswerGuy (guest, #1256)
[Link]
I think these system changes (planned for 2.8 now anyway) will do away devfs is a good idea. However, it's a BIG change and will have to be I think combining devfs's dynamic model with the massive naming and We are seeking the "backwards" part of "backwards compatibility here.
Posted Nov 14, 2002 7:59 UTC (Thu)
by eru (subscriber, #2753)
[Link] (4 responses)
Mandrake Linux, a very popular distro, has had devfs activated
Posted Nov 14, 2002 11:44 UTC (Thu)
by csawtell (guest, #986)
[Link]
Posted Nov 15, 2002 3:04 UTC (Fri)
by melauer (guest, #2438)
[Link] (2 responses)
Posted Nov 16, 2002 13:17 UTC (Sat)
by ernest (guest, #2355)
[Link] (1 responses)
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.
Posted Nov 25, 2002 3:34 UTC (Mon)
by elanthis (guest, #6227)
[Link]
Posted Nov 14, 2002 13:46 UTC (Thu)
by brugolsky (guest, #28)
[Link] (1 responses)
Of course, Ted has a point; there are other things that might profit more from Al's chainsaw.
Posted Nov 21, 2002 16:10 UTC (Thu)
by Baylink (guest, #755)
[Link]
Heh. :-)
Posted Nov 14, 2002 16:00 UTC (Thu)
by a9db0 (subscriber, #2181)
[Link] (1 responses)
Gentoo may be considered a "minor" distribution, but its popularity is growing rapidly. Just browse through the comments in the current poll on slashdot.
Posted Nov 22, 2002 2:17 UTC (Fri)
by yem (guest, #1138)
[Link]
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.
Posted Nov 14, 2002 20:30 UTC (Thu)
by ernest (guest, #2355)
[Link]
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. 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.
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.
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.
Posted Nov 21, 2002 6:40 UTC (Thu)
by darthmdh (guest, #8032)
[Link]
Posted Nov 21, 2002 11:47 UTC (Thu)
by TheOneKEA (guest, #615)
[Link]
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.
Posted Nov 21, 2002 12:07 UTC (Thu)
by job (guest, #670)
[Link]
Posted Nov 21, 2002 17:52 UTC (Thu)
by MLKahnt (guest, #6642)
[Link]
The problem with devfs is that it hasn't got the support of the rest What's to become of devfs?
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."
with devfsd --- which seems like a kludge like kerneld did.
adopted slowly, probably will need more support (such as this unionfs
feature) and the implementation probably does need to be cleaned up.
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.
> Despite the fact that devfs has been in the 2.4 kernel since it firstWhat's to become of devfs?
> shipped, very few distributions are turning it on for their customers.
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.
Gentoo uses it, so I use it. It works well. Please don't take it away.
What's to become of devfs?
Also, note that Debian is still on kernel 2.2, which means that devfs isn't even an option for that distro.
What's to become of devfs?
Hu ? I use Debian, it has all the kernels you wish.debian only has kernel 2.2.x ??
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.
debian only has kernel 2.2.x ??
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.)What's to become of devfs?
"Al's chainsaw".What's to become of devfs?
Gentoo ships with devfs enabled, and in fact won't run without it in its standard config.What's to become of devfs?
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.What's to become of devfs?
I have it switched on
devfs is beter.
too many name changes.
Ummm... devfs?
Ummm... devfs?
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).What's to become of devfs?
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.
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.What's to become of devfs?
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.
Keep devfs!
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.
What's to become of devfs?