readme

linux-2.6.15.6

Devfs (Device File System) FAQ


Linux Devfs (Device File System) FAQ
Richard Gooch
20-AUG-2002


Document languages:







-----------------------------------------------------------------------------

NOTE: the master copy of this document is available online at:

http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html
and looks much better than the text version distributed with the
kernel sources. A mirror site is available at:

http://www.ras.ucalgary.ca/~rgooch/linux/docs/devfs.html

There is also an optional daemon that may be used with devfs. You can
find out more about it at:

http://www.atnf.csiro.au/~rgooch/linux/

A mailing list is available which you may subscribe to. Send
email
to [e-mail] with the following line in the
body of the message:
subscribe devfs
To unsubscribe, send the message body:
unsubscribe devfs
instead. The list is archived at

http://oss.sgi.com/projects/devfs/archive/.

-----------------------------------------------------------------------------

Contents


What is it?

Why do it?

Who else does it?

How it works

Operational issues (essential reading)

Instructions for the impatient
Permissions persistence across reboots
Dealing with drivers without devfs support
All the way with Devfs
Other Issues
Kernel Naming Scheme
Devfsd Naming Scheme
Old Compatibility Names
SCSI Host Probing Issues



Device drivers currently ported

Allocation of Device Numbers

Questions and Answers

Making things work
Alternatives to devfs
What I don't like about devfs
How to report bugs
Strange kernel messages
Compilation problems with devfsd


Other resources

Translations of this document


-----------------------------------------------------------------------------


What is it?

Devfs is an alternative to "real" character and block special devices
on your root filesystem. Kernel device drivers can register devices by
name rather than major and minor numbers. These devices will appear in
devfs automatically, with whatever default ownership and
protection the driver specified. A daemon (devfsd) can be used to
override these defaults. Devfs has been in the kernel since 2.3.46.

NOTE that devfs is entirely optional. If you prefer the old
disc-based device nodes, then simply leave CONFIG_DEVFS_FS=n (the
default). In this case, nothing will change.  ALSO NOTE that if you do
enable devfs, the defaults are such that full compatibility is
maintained with the old devices names.

There are two aspects to devfs: one is the underlying device
namespace, which is a namespace just like any mounted filesystem. The
other aspect is the filesystem code which provides a view of the
device namespace. The reason I make a distinction is because devfs
can be mounted many times, with each mount showing the same device
namespace. Changes made are global to all mounted devfs filesystems.
Also, because the devfs namespace exists without any devfs mounts, you
can easily mount the root filesystem by referring to an entry in the
devfs namespace.


The cost of devfs is a small increase in kernel code size and memory
usage. About 7 pages of code (some of that in __init sections) and 72
bytes for each entry in the namespace. A modest system has only a
couple of hundred device entries, so this costs a few more
pages. Compare this with the suggestion to put /dev on a <a
href="#why-faq-ramdisc">ramdisc.

On a typical machine, the cost is under 0.2 percent. On a modest
system with 64 MBytes of RAM, the cost is under 0.1 percent.  The
accusations of "bloatware" levelled at devfs are not justified.

-----------------------------------------------------------------------------


Why do it?

There are several problems that devfs addresses. Some of these
problems are more serious than others (depending on your point of
view), and some can be solved without devfs. However, the totality of
these problems really calls out for devfs.

The choice is a patchwork of inefficient user space solutions, which
are complex and likely to be fragile, or to use a simple and efficient
devfs which is robust.

There have been many counter-proposals to devfs, all seeking to
provide some of the benefits without actually implementing devfs. So
far there has been an absence of code and no proposed alternative has
been able to provide all the features that devfs does. Further,
alternative proposals require far more complexity in user-space (and
still deliver less functionality than devfs). Some people have the
mantra of reducing "kernel bloat", but don't consider the effects on
user-space.

A good solution limits the total complexity of kernel-space and
user-space.


Major&minor allocation

The existing scheme requires the allocation of major and minor device
numbers for each and every device. This means that a central
co-ordinating authority is required to issue these device numbers
(unless you're developing a "private" device driver), in order to
preserve uniqueness. Devfs shifts the burden to a namespace. This may
not seem like a huge benefit, but actually it is. Since driver authors
will naturally choose a device name which reflects the functionality
of the device, there is far less potential for namespace conflict.
Solving this requires a kernel change.

/dev management

Because you currently access devices through device nodes, these must
be created by the system administrator. For standard devices you can
usually find a MAKEDEV programme which creates all these (hundreds!)
of nodes. This means that changes in the kernel must be reflected by
changes in the MAKEDEV programme, or else the system administrator
creates device nodes by hand.

The basic problem is that there are two separate databases of
major and minor numbers. One is in the kernel and one is in /dev (or
in a MAKEDEV programme, if you want to look at it that way). This is
duplication of information, which is not good practice.
Solving this requires a kernel change.

/dev growth

A typical /dev has over 1200 nodes! Most of these devices simply don't
exist because the hardware is not available. A huge /dev increases the
time to access devices (I'm just referring to the dentry lookup times
and the time taken to read inodes off disc: the next subsection shows
some more horrors).

An example of how big /dev can grow is if we consider SCSI devices:

host           6  bits  (say up to 64 hosts on a really big machine)
channel        4  bits  (say up to 16 SCSI buses per host)
id             4  bits
lun            3  bits
partition      6  bits
TOTAL          23 bits


This requires 8 Mega (1024*1024) inodes if we want to store all
possible device nodes. Even if we scrap everything but id,partition
and assume a single host adapter with a single SCSI bus and only one
logical unit per SCSI target (id), that's still 10 bits or 1024
inodes. Each VFS inode takes around 256 bytes (kernel 2.1.78), so
that's 256 kBytes of inode storage on disc (assuming real inodes take
a similar amount of space as VFS inodes). This is actually not so bad,
because disc is cheap these days. Embedded systems would care about
256 kBytes of /dev inodes, but you could argue that embedded systems
would have hand-tuned /dev directories. I've had to do just that on my
embedded systems, but I would rather just leave it to devfs.

Another issue is the time taken to lookup an inode when first
referenced. Not only does this take time in scanning through a list in
memory, but also the seek times to read the inodes off disc.
This could be solved in user-space using a clever programme which
scanned the kernel logs and deleted /dev entries which are not
available and created them when they were available. This programme
would need to be run every time a new module was loaded, which would
slow things down a lot.

There is an existing programme called scsidev which will automatically
create device nodes for SCSI devices. It can do this by scanning files
in /proc/scsi. Unfortunately, to extend this idea to other device
nodes would require significant modifications to existing drivers (so
they too would provide information in /proc). This is a non-trivial
change (I should know: devfs has had to do something similar). Once
you go to this much effort, you may as well use devfs itself (which
also provides this information).  Furthermore, such a system would
likely be implemented in an ad-hoc fashion, as different drivers will
provide their information in different ways.

Devfs is much cleaner, because it (naturally) has a uniform mechanism
to provide this information: the device nodes themselves!


Node to driver file_operations translation

There is an important difference between the way disc-based character
and block nodes and devfs entries make the connection between an entry
in /dev and the actual device driver.

With the current 8 bit major and minor numbers the connection between
disc-based c&b nodes and per-major drivers is done through a
fixed-length table of 128 entries. The various filesystem types set
the inode operations for c&b nodes to {chr,blk}dev_inode_operations,
so when a device is opened a few quick levels of indirection bring us
to the driver file_operations.

For miscellaneous character devices a second step is required: there
is a scan for the driver entry with the same minor number as the file
that was opened, and the appropriate minor open method is called. This
scanning is done *every time* you open a device node. Potentially, you
may be searching through dozens of misc. entries before you find your
open method. While not an enormous performance overhead, this does
seem pointless.

Linux *must* move beyond the 8 bit major and minor barrier,
somehow. If we simply increase each to 16 bits, then the indexing
scheme used for major driver lookup becomes untenable, because the
major tables (one each for character and block devices) would need to
be 64 k entries long (512 kBytes on x86, 1 MByte for 64 bit
systems). So we would have to use a scheme like that used for
miscellaneous character devices, which means the search time goes up
linearly with the average number of major device drivers on your
system. Not all "devices" are hardware, some are higher-level drivers
like KGI, so you can get more "devices" without adding hardware
You can improve this by creating an ordered (balanced:-)
binary tree, in which case your search time becomes log(N).
Alternatively, you can use hashing to speed up the search.
But why do that search at all if you don't have to? Once again, it
seems pointless.

Note that devfs doesn't use the major&minor system. For devfs
entries, the connection is done when you lookup the /dev entry. When
devfs_register() is called, an internal table is appended which has
the entry name and the file_operations. If the dentry cache doesn't
have the /dev entry already, this internal table is scanned to get the
file_operations, and an inode is created. If the dentry cache already
has the entry, there is *no lookup time* (other than the dentry scan
itself, but we can't avoid that anyway, and besides Linux dentries
cream other OS's which don't have them:-). Furthermore, the number of
node entries in a devfs is only the number of available device
entries, not the number of *conceivable* entries. Even if you remove
unnecessary entries in a disc-based /dev, the number of conceivable
entries remains the same: you just limit yourself in order to save
space.

Devfs provides a fast connection between a VFS node and the device
driver, in a scalable way.

/dev as a system administration tool

Right now /dev contains a list of conceivable devices, most of which I
don't have. Devfs only shows those devices available on my
system. This means that listing /dev is a handy way of checking what
devices are available.

Major&minor size

Existing major and minor numbers are limited to 8 bits each. This is
now a limiting factor for some drivers, particularly the SCSI disc
driver, which consumes a single major number. Only 16 discs are
supported, and each disc may have only 15 partitions. Maybe this isn't
a problem for you, but some of us are building huge Linux systems with
disc arrays. With devfs an arbitrary pointer can be associated with
each device entry, which can be used to give an effective 32 bit
device identifier (i.e. that's like having a 32 bit minor
number). Since this is private to the kernel, there are no C library
compatibility issues which you would have with increasing major and
minor number sizes. See the section on "Allocation of Device Numbers"
for details on maintaining compatibility with userspace.

Solving this requires a kernel change.

Since writing this, the kernel has been modified so that the SCSI disc
driver has more major numbers allocated to it and now supports up to
128 discs. Since these major numbers are non-contiguous (a result of
unplanned expansion), the implementation is a little more cumbersome
than originally.

Just like the changes to IPv4 to fix impending limitations in the
address space, people find ways around the limitations. In the long
run, however, solutions like IPv6 or devfs can't be put off forever.

Read-only root filesystem

Having your device nodes on the root filesystem means that you can't
operate properly with a read-only root filesystem. This is because you
want to change ownerships and protections of tty devices. Existing
practice prevents you using a CD-ROM as your root filesystem for a
*real* system. Sure, you can boot off a CD-ROM, but you can't change
tty ownerships, so it's only good for installing.

Also, you can't use a shared NFS root filesystem for a cluster of
discless Linux machines (having tty ownerships changed on a common
/dev is not good). Nor can you embed your root filesystem in a
ROM-FS.

You can get around this by creating a RAMDISC at boot time, making
an ext2 filesystem in it, mounting it somewhere and copying the
contents of /dev into it, then unmounting it and mounting it over
/dev.

A devfs is a cleaner way of solving this.

Non-Unix root filesystem

Non-Unix filesystems (such as NTFS) can't be used for a root
filesystem because they variously don't support character and block
special files or symbolic links. You can't have a separate disc-based
or RAMDISC-based filesystem mounted on /dev because you need device
nodes before you can mount these. Devfs can be mounted without any
device nodes. Devlinks won't work because symlinks aren't supported.
An alternative solution is to use initrd to mount a RAMDISC initial
root filesystem (which is populated with a minimal set of device
nodes), and then construct a new /dev in another RAMDISC, and finally
switch to your non-Unix root filesystem. This requires clever boot
scripts and a fragile and conceptually complex boot procedure.

Devfs solves this in a robust and conceptually simple way.

PTY security

Current pseudo-tty (pty) devices are owned by root and read-writable
by everyone. The user of a pty-pair cannot change
ownership/protections without being suid-root.