Device File System GuideSven VermeulenSeemant Kulleen
In this document you'll find information on what devfs is really about
and how to work with it.
0.62005-07-21What is devfs?The (good?) old days
devfs is obsolete and has been removed from the stable 2.6 tree in the
2.6.13 release. Users on 2.6 kernels are hereby advised to switch to udev. For
further information on udev, please refer to the Gentoo udev Guide.

Traditional Linux implementations provide their users with an
abstract device path, called /dev. Inside this path the
user finds device nodes, special files that represent devices
inside their system. For instance, /dev/hda 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:

# ls -l /dev/hda
brw-rw---- 1 root disk 3, 0 Jul 5 2000 /dev/hda

In the previous example we see that /dev/hda 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 /dev/hda4 and /dev/tty5. 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 /dev, 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 ./MAKEDEV inside the
/dev 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
/dev on a seperate partition, since mount needs
/dev 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.

Navigating through the device treeDirectories

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
/dev/ide/ device directory, and SCSI-related devices are inside
/dev/scsi/. 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, lun0/.

So, whereas /dev/hda4 was used previously, we now have
/dev/ide/host0/bus0/target0/lun0/part4. This is far more
easy... no, don't argue with me... it is easier... ah whatever!
:)

You can also use more Unix-like device file naming for hard disks, such as
c0b0t0u0p2. They can be found in /dev/ide/hd,
/dev/scsi/hd etc.

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

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,
devfsd is created. This daemon creates symlinks with the old
names, pointing to the new device files.

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

# Comment the following two lines out to remove the symlinks
REGISTER .* MKOLDCOMPAT
UNREGISTER .* RMOLDCOMPAT

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:

LOOKUP .* MODLOAD

Permission Related ItemsSet/change permissions with devfsd
These instructions are valid as long as pam_console is disabled in
/etc/pam.d/system-auth. If you enabled pam_console there,
then PAM has the final word on permissions.

If you want to set permissions using /etc/devfsd.conf,
then use the syntax used in the following example:

REGISTER ^cdroms/.* PERMISSIONS root.cdrom 0660

The second field is the device group, starting from /dev.
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 chown (CHange
OWNer) and chmod (CHange MODe) some device files, devfsd
will save the information so that it will persist across reboots. This
is because the /etc/devfsd.conf file contains the
following lines:

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

Another possibility is to mount /lib/dev-state on
/dev 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 /dev/console exists. Then, somewhere
at the beginning of the bootscripts of your system, you place:

mount --bind /dev /lib/dev-state
mount -t devfs none /dev
devfsd /dev

Resources

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

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

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: