Ummm... devfs?

Posted Nov 17, 2002 4:51 UTC (Sun) by JLCdjinn (guest, #1905)
Parent article: What's to become of devfs?

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.