devfs for Management and Administration

Traditionally in a UNIX-style operating
system, processes access devices via the /dev directory. Within
this directory are hundreds of device nodes allocated as either
block or character devices, each with a major and minor number that
corresponds to its device driver and its device instance.
Therefore, whenever a new device is supported by the kernel, you
have to create a node in /dev that corresponds to the new device so
processes are able to access it. This habit can become tedious and
makes life as system administrator a little more complex.A lot of other problems come with having /dev on disk. For
one, managing permissions and device nodes not in use can be
time-consuming and overly complex. Another major problem with
having /dev on a disk is you cannot mount a read-only root
filesystem that is practical for everyday use. There are also the
issues of /dev growth and having a non-UNIX root filesystem.devfs provides a solution to
these problems and also gives system administrators a new tool for
checking which devices are available. devfs is written as a virtual
filesystem driver, and it keeps track of the device drivers
currently registered while also automatically creating and removing
the corresponding device nodes in /dev. devfs is comprised of three
different parts, but as a system administrator you will interact
only with two of them. The first part is the kernel VFS module. The
part of devfs that you will not deal with as a system administrator
is the kernel API that devfs provides to drivers.Each driver in use must have devfs_register() and
devfs_unregister() calls to work with devfs. If you would like more
details on how to write drivers that function with devfs, check out
Richard Gooch's web site in the resource section. The final piece
of the devfs puzzle is called devfsd. devfsd is a system
dæmon that does all the ugly tasks, including managing
permissions, maintaining symbolic links within /dev and a host of
other things that go beyond the scope of this article.Problems with a Disk-Based /devManaging /dev can be a big pain in the rump. For starters, on
a typical system there are over 1,200 device nodes. And out of
those, only a couple hundred are ever used. This results in an
extremely messy /dev directory. How many of you out there actually
go through and clean up all the entries in /dev that correspond to
hardware you don't have and probably never will have? Not many I
bet. Not doing the cleanup does not seem to be too big of a
deal--device nodes do not take up a lot of space, and we all have
multigigabyte hard drives. But skipping the cleanup can be somewhat
problematic because /dev grows as device lookup time is
increased.With devfs in place, you now have an intelligent device
management scheme that creates and removes nodes in /dev when you
load and unload the kernel device driver modules. This is taken
care of at the kernel level, so as a system administrator you do
not have to worry about a thing. Having dynamic device node
creation also allows you to use the /dev as an administration
utility to see if you hardware is installed properly.Yet another problem with having /dev on a disk is you cannot
mount a practical read-only root filesystem. When you are working
with embedded systems, this factor can be crucial. By having /dev
on a disk, if you were to mount the root filesystem as read-only,
you would not be able change tty ownerships. This results in a slew
of problems and security issues. The other problem relating to this
is having a non-UNIX root filesystem, because the majority of
non-UNIX filesystems do not support characters and block special
files or symbolic links. devfs fixes both of these problems because
the /dev is now mounted as a virtual filesystem in a read-write
mode and is not dependent on the state of the root
filesystem.Installing devfs and devfsdGetting devfs up and running on your system is a fairly easy
task and can be completed on a Saturday afternoon. The steps
involved are rebuilding the kernel, installing the new kernel,
building devfsd, installing devfsd, configuring devfsd and
rebooting. If you are unfamiliar with rebuilding your kernel, you
should either wait until your distribution is shipping kernel
packages with devfs support or check out the Linux Kernel HOWTO
(see Resources).The first step in installing devfs is insuring that your
kernel has devfs support built-in. You can do a quick check to see
if your currently running kernel has devfs support by
executing:grep devfs /proc/filesystemsIf your kernel has devfs you should see:nodev devfsIf you do not have devfs support in your kernel, you are
going to need to build a new kernel, specifically kernel 2.4.10 or
greater. I would recommend getting the latest kernel source from
www.kernel.org; for this
article I was using 2.4.18. Configure the kernel to your liking
with your favorite configuration method and add the following
options:

CONFIG_EXPERIMENTAL
CONFIG_DEVFS_FS
CONFIG_DEVFS_MOUNT

You also should disable dev pts since devfs now takes care of
this process. (Various users have reported that leaving dev pts
enabled creates serious operational problems with devfs.) Install
your spiffy new kernel, and do not forget to make a backup of your
old one in case something goes awry.You are now ready to install devfsd. devfsd is the portion of
devfs that manages permissions, symbolic links, compatibility
issues and other miscellaneous things. While it is not required for
you to run devfsd, it is highly recommended; if you do not run it,
all of your software must be configured to point to the new
locations in /dev. Go out and download the latest version of devfsd
from
Richard
Gooch's web site. As of this writing, the latest version is
1.3.25. Compiling and installing devfsd is pretty typical. The only
minor change is if you do not keep your kernel in /usr/src/linux,
you should set the environment variable KERNEL_DIR to point your
kernel source directory. Extract and install devfsd:

tar -xzvf devfsd-v1.3.25.tar.gz
cd devfsd/ 
make && make install

After installing devfsd you will need to create a startup
script and modify the devfsd.conf file to your liking. The startup
script for devfsd should run before anything else, so any
dæmon or process that accesses /dev in the old way will still
run. See Listing 1 for a basic startup script. Installing the
startup script is going to be different for individual
distributions. For Debian GNU/Linux, copy the devfsd script to
/etc/init.d and create a symbolic link to /etc/rcS.d/S01devfsd, so
devfsd always gets started. You also will want to link shutdown
scripts to /etc/rc1.d/K99devfsd and /etc/rc6.d/K99devfsd. Refer to
your distributions documentation on how and where to place new
startup scripts.Listing 1. Basic devfsd Startup
ScriptThe next step to getting devfs up and running on your system
is to configure devfsd. The configuration file for devfsd is
located at /etc/devfsd.conf (see Listing 2). This file allows you
to tweak devfsd to do almost anything relating to /dev.Listing 2.
/etc/devfsd.confI like to keep my devfsd configuration pretty simple and
include only compatibility entries, module auto-loading and /dev
permissions. The following two lines in devfsd.conf create
compatibility symlinks to the old device names, so all your
currently configured software still works:

REGISTER                .*      MKOLDCOMPAT
UNREGISTER      .*      RMOLDCOMPAT

If you want to enable the module auto-loading functionality,
add this line:

LOOKUP          .*      MODLOAD

This brings us to something that frustrates a lot of people
when they first start using devfs. How do I get my permissions to
come back after a reboot? This question has many answers: you can
create a tarball of all the changed inodes prior to shutdown and
then untar them during startup; you can store your permissions on a
disk-based /dev and have devfsd copy and save them when starting up
and shutting down; or you could simply add PERMISSIONS entries to
your /etc/devfsd.conf file. Managing the device permissions for
devfs in devfsd.conf via PERMISSIONS entries is great--you can have
one entry for an entire group of devices. The following are some
basic permissions I set up on my workstation:

REGISTER        ^cdroms/.*      PERMISSIONS     root.cdrom 0660
REGISTER        ^pty/s.*        PERMISSIONS     root.tty  0600
REGISTER        ^sound/.*       PERMISSIONS     root.audio 0660
REGISTER        ^tts/.*         PERMISSIONS     root.dip 0660

What those entries do is fairly simple. All the devices that
are found under /dev/cdroms now have root as the owning user and
cdrom as the owning group, with 0660 permissions, or u+rw g+rw
o-rwx. I find this to be the easiest way to manage permissions.
Using devfsd to manage permissions also prevents you from doing a
quick chmod on a device when you first install it, telling yourself
that you will set up the permissions correctly later and, of
course, quickly forgetting that promise.Getting to Know devfsSo you've done all the prerequisite steps, configured the
kernel, installed it, added the devfsd startup script to your init
directories and configured devfsd. Now it's time to reboot and
checkout your new fancy devfs. After rebooting, you should be up
and running with /dev mounted as a devfs filesystem. You can double
check this by executing cat /proc/mounts. You
should see a line that says none /dev devfs rw 0
0; if you don't see it, something went wrong. Double
check that you configured everything properly, and look at your
logs for any errors relating to devfs or devfsd.Now that you have devfs up and running, poke around in /dev
and check out how the symbolic links are set up from the different
devices. One of the major changes is how the disk nodes are set up.
If you look under /dev/discs, you'll see an entry for each physical
hard disk installed on your system. If you look at the destination
of the symbolic links, you will notice they point to an entry in
either /dev/ide or /dev/scsi, depending on the type of interface
you are using.The entries in /dev/ide and /dev/scsi are fairly
straight-forward. The first level is hostX; these entries
correspond to the IDE and SCSI controllers you have installed on
your system. For example, if you have an on-board IDE controller
and a PCI card with an IDE controller, host0 will point to the
on-board controller and host1 will point to the PCI cards
controller. The next level is busX for IDE devices, which
corresponds to the primary and secondary controllers. The next
level is targetX. This typically corresponds to the physical drive
itself. When using the IDE, target0 would point to your master
drive and target1 to your slave device. After the target you have
lunX entries. IDE devices only have one lun, so this will always be
lun0. But if you have a SCSI system, the devices can have multiple
luns, similar to a cd changer.Now you are at a level that actually points to a device.
Within the lunX directory are the actual nodes that point to the
disk, the partitions or other type of device. For example, a hard
disk with four partitions will have five entries within the lunX
entry. These will be disk, part1, part2, part3 and part4. If this
is the first disk on the system, disk would correspond to the old
/dev/hda, part1 would correspond to the old /dev/hda1 and so on.
You can see that devfs manages devices with a logical name-space
and is quite easy to navigate.Now you might want to start editing your various
configuration files to point to the new device locations instead of
the old style entries. A good starting place is /etc/fstab. From
what you learned above, you can deduce that your old /dev/hda6 is
now located at /dev/discs/disc0/part6. I find that to be the
easiest name-space to use, but you also could point it to the IDE
name-space at /dev/ide/host0/bus0/target0/lun0/part6. Either way
will get the job done, but by using the generic /dev/discs and
/dev/cdroms you won't have to modify a bunch of configuration files
if you move from IDE to SCSI down the road.ConclusionYou have seen how devfs provides a unique solution to the
problems with a disk-based /dev. While it may not be the perfect
solution, devfs and devfsd do solve a variety of problems and also
provide you with an administration utility to see the current state
of devices. By combining an intelligent device management scheme
with a powerful dæmon to manage permissions and symbolic
links, you can keep your systems /dev structure lean, clean and
mean.ResourcesKernel
SourcesThe
Linux Kernel-HOWTORichard
Gooch's Home PagePhilip Streck is an
applications programmer for Akron General Medical Center, an
independent consultant and specializes in Palm OS applications. He
is also currently obtaining a BS in Computer Science at the
University of Akron.

email: pstreck@phantasmal-inc.com