User:SwifT/Wikified but not merged documents/DevFS Guide

In this document you'll find information on what devfs is really about and how to work with it.

The (good?) old days
Traditional Linux implementations provide their users with an abstract device path, called. Inside this path the user finds device nodes, special files that represent devices inside their system. For instance, represents the first IDE device in their system. By providing device files to the users, they can create programs that interact with hardware as if the hardware was a regular file instead of using special APIs.

The device files are split in two groups, called character devices and block devices. The first group consists of hardware of which read/writes are not buffered. The second group naturally consists of hardware of which read/writes are buffered. Both devices can be read one character at a time, or in blocks. Therefore, the naming might sound confusing and in fact is wrong.

If you take a look at a certain device file, you might find something like this:

Checking the information of a device file

In the previous example we see that is a block device. However, more importantly, it has two special numbers assigned to it: 3, 0. This pair is called the major-minor pair. It is used by the kernel to map a device file to a real device. The major corresponds with a certain device, the minor with a subdevice. Seems confusing? It isn't.

Two examples are and. The first device file corresponds with the fourth partition on the first IDE device. Its major-minor pair is 3, 4. In other words, the minor corresponds with the partition where the major corresponds with the device. The second example has 4, 5 as major-minor pair. In this case, the major corresponds with the terminal driver, while the minor corresponds with the terminal number (in this case, the fifth terminal).

The problems
If you do a quick check in such a, you'll find out that not only all your devices are listed, but all possible devices that you can imagine. In other words, you have device files for devices you don't have. Managing such a device group is cumbersome to say the least. Imagine having to change the permissions of all device files that have a corresponding device in your system, and leaving the rest of the device files as they are.

When you add new hardware to your system, and this hardware didn't have a device file previously, you would have to create one. Advanced users know that this task can be accomplished with  inside the  tree, but do you immediately know what device you have to create?

When you have programs interacting with hardware using the device files, you can't have the root partition mounted read only, while there is no further need to have it mounted read-write. And you can't have on a seperate partition, since   needs  to mount partitions.

The solutions
As you can imagine, the kernel hackers have found quite a number of solutions to the aforementioned problems. However, many of them had other flaws as described in http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#faq-why. We are not going to talk about these implementations, but focus on the one implementation that did make it to the official kernel sources: devfs.

devfs as all-round winner ?
devfs tackles all listed problems. It only provides the user with existing devices, adds new nodes when new devices are found, and makes it possible to mount the root filesystem read only. And it tackles more problems we haven't discussed previously because they are less interesting for users...

For instance, with devfs, you don't have to worry about major/minor pairs. It is still supported (for backwards compatibility), but isn't needed. This makes it possible for Linux to support even more devices, since there are no limits anymore (numbers always have boundaries :)

Yet devfs does come with it's own problems; for the end users these issues aren't really visible, but for the kernel maintainers the problems are big enough to mark devfs obsolete in favor of udev, which Gentoo supports and uses by default on most architectures since the 2005.0 release when using a 2.6 kernel.

For more information as to why devfs is marked obsolete, please read the udev FAQ and udev versus devfs document.

Directories
One of the first things you might notice is that devfs uses directories to group devices together. This improves readability, as now all related devices are inside a common directory.

For instance, all IDE-related devices are inside the device directory, and SCSI-related devices are inside. SCSI and IDE disks are seen in the same way, meaning they both have the same subdirectory structure.

IDE and SCSI disks are controlled by an adapter (on-board or a seperate card), called the host. Every adapter can have several channels. A channel is called a bus. On each channel, you can have several IDs. Such an ID identifies a disk. This ID is called the target. Some SCSI devices can have multiple luns ( Logical Unit Numbers ), for instance devices that handle multiple media simultaneously (hi-end tapedrives). You mostly have only a single lun,.

So, whereas was used previously, we now have. This is far more easy... no, don't argue with me... it is easier... ah whatever! :)

To give you an idea on the directories, this is a listing of the directories which I have on my laptop:

Directories in /dev

Backwards compatibility using devfsd
Using this new scheme sounds fun, but several tools and programs make use of the previous, old scheme. To make sure no system is broken,  is created. This daemon creates symlinks with the old names, pointing to the new device files.

Created symlinks

With , you can also set the permissions, create new device files, define actions etc. All this is described in the next chapter.

Restarting devfsd
When you alter the file, and you want the changes to be forced onto the system, you don't have to reboot. Depending on what you want, you can use any of the two following signals:

SIGHUP will have reread the configuration file, reload the shared objects and generate the REGISTER events for each leaf node in the device tree.

SIGUSR1 will do the same, but won't generate REGISTER events.

To send a signal, simply use  or   :

Sending the SIGHUP signal to devfsd

Removing compatibility symlinks
If you want the compatibility symlinks that clutter up removed from your Gentoo system (Gentoo activates it per default), edit  and remove the following two lines:

/etc/devfsd.conf for backwards compatibility

You need to reboot your system for the changes to take affect.

Removing autoload functionality
When you load a module, devfs will automatically create the device files. If you don't want this behaviour, remove the following line from :

/etc/devfsd.conf, autoload functionality

Set/change permissions with devfsd
If you want to set permissions using, then use the syntax used in the following example:

Permissions in /etc/devfsd.conf

The second field is the device group, starting from. It is a regular expression, meaning you can select several device files in one rule.

The fourth field is the ownership of the device file, and the fifth field contains the permissions of the device file.

Manually set permissions and have devfsd save it
This is the default behaviour for Gentoo: if you  (CHange OWNer) and   (CHange MODe) some device files,   will save the information so that it will persist across reboots. This is because the file contains the following lines:

/etc/devfsd.conf for saving permissions

In other words, changed device files are copied over to as soon as the change happens, and are copied over to  when booting the system.

Another possibility is to mount on  at boot-time. To do this, you must make sure that devfs is not mounted automatically (meaning you'll have to recompile your kernel) and that exists. Then, somewhere at the beginning of the bootscripts of your system, you place:

Mounting /lib/dev-state on top of /dev

Resources
For more information on devfs, check out the following resources.

The devfsd.conf manpage explains the syntax of the file. To view it, type.

The devfs FAQ explains everything about devfs. It also contains information about the internal devfs structure and how drivers can support devfs.

On LinuxJournal there is an interesting article on devfs for Management and Administration.

Daniel Robbins has written a set of articles for IBM's DeveloperWorks about Advanced filesystems. Three of them are about devfs:


 * Introduction to devfs
 * Setting up devfs
 * Implementing devfs

Acknowledgements
We would like to thank the following authors and editors for their contributions to this guide:


 * Sven Vermeulen
 * Seemant Kulleen