readme

linux-2.6.15.6

Now you may feel like changing the configuration (common targets are
/etc/fstab and /etc/devfsd.conf). Since you have a
system that works, if you make any changes and it doesn't work, you
now know that you only have to restore your configuration files to the
default and it will work again.


Permissions persistence across reboots

If you don't use mknod(2) to create a device file, nor use chmod(2) or
chown(2) to change the ownerships/permissions, the inode ctime will
remain at 0 (the epoch, 12 am, 1-JAN-1970, GMT). Anything with a ctime
later than this has had it's ownership/permissions changed. Hence, a
simple script or programme may be used to tar up all changed inodes,
prior to shutdown. Although effective, many consider this approach a
kludge.

A much better approach is to use devfsd to save and restore
permissions. It may be configured to record changes in permissions and
will save them in a database (in fact a directory tree), and restore
these upon boot. This is an efficient method and results in immediate
saving of current permissions (unlike the tar approach, which saves
permissions at some unspecified future time).

The default configuration file supplied with devfsd has config entries
which you may uncomment to enable persistence management.

If you decide to use the tar approach anyway, be aware that tar will
first unlink(2) an inode before creating a new device node. The
unlink(2) has the effect of breaking the connection between a devfs
entry and the device driver. If you use the "devfs=only" boot option,
you lose access to the device driver, requiring you to reload the
module. I consider this a bug in tar (there is no real need to
unlink(2) the inode first).

Alternatively, you can use devfsd to provide more sophisticated
management of device permissions. You can use devfsd to store
permissions for whole groups of devices with a single configuration
entry, rather than the conventional single entry per device entry.

Permissions database stored in mounted-over /dev

If you wish to save and restore your device permissions into the
disc-based /dev while still mounting devfs onto /dev
you may do so. This requires a 2.4.x kernel (in fact, 2.3.99 or
later), which has the VFS binding facility. You need to do the
following to set this up:



make sure the kernel does not mount devfs at boot time


make sure you have a correct /dev/console entry in your
root file-system (where your disc-based /dev lives)

create the /dev-state directory


add the following lines near the very beginning of your boot
scripts:

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




add the following lines to your /etc/devfsd.conf file:

REGISTER	^pt[sy]		IGNORE
CREATE		^pt[sy]		IGNORE
CHANGE		^pt[sy]		IGNORE
DELETE		^pt[sy]		IGNORE
REGISTER	.*		COPY	/dev-state/$devname $devpath
CREATE		.*		COPY	$devpath /dev-state/$devname
CHANGE		.*		COPY	$devpath /dev-state/$devname
DELETE		.*		CFUNCTION GLOBAL unlink /dev-state/$devname
RESTORE		/dev-state

Note that the sample devfsd.conf file contains these lines,
as well as other sample configurations you may find useful. See the
devfsd distribution


reboot.




Permissions database stored in normal directory

If you are using an older kernel which doesn't support VFS binding,
then you won't be able to have the permissions database in a
mounted-over /dev. However, you can still use a regular
directory to store the database. The sample /etc/devfsd.conf
file above may still be used. You will need to create the
/dev-state directory prior to installing devfsd. If you have
old permissions in /dev, then just copy (or move) the device
nodes over to the new directory.

Which method is better?

The best method is to have the permissions database stored in the
mounted-over /dev. This is because you will not need to copy
device nodes over to /dev-state, and because it allows you to
switch between devfs and non-devfs kernels, without requiring you to
copy permissions between /dev-state (for devfs) and
/dev (for non-devfs).


Dealing with drivers without devfs support

Currently, not all device drivers in the kernel have been modified to
use devfs. Device drivers which do not yet have devfs support will not
automagically appear in devfs. The simplest way to create device nodes
for these drivers is to unpack a tarfile containing the required
device nodes. You can do this in your boot scripts. All your drivers
will now work as before.

Hopefully for most people devfs will have enough support so that they
can mount devfs directly over /dev without losing most functionality
(i.e. losing access to various devices). As of 22-JAN-1998 (devfs
patch version 10) I am now running this way. All the devices I have
are available in devfs, so I don't lose anything.

WARNING: if your configuration requires the old-style device names
(i.e. /dev/hda1 or /dev/sda1), you must install devfsd and configure
it to maintain compatibility entries. It is almost certain that you
will require this. Note that the kernel creates a compatibility entry
for the root device, so you don't need initrd.

Note that you no longer need to mount devpts if you use Unix98 PTYs,
as devfs can manage /dev/pts itself. This saves you some RAM, as you
don't need to compile and install devpts. Note that some versions of
glibc have a bug with Unix98 pty handling on devfs systems. Contact
the glibc maintainers for a fix. Glibc 2.1.3 has the fix.

Note also that apart from editing /etc/fstab, other things will need
to be changed if you *don't* install devfsd. Some software (like the X
server) hard-wire device names in their source. It really is much
easier to install devfsd so that compatibility entries are created.
You can then slowly migrate your system to using the new device names
(for example, by starting with /etc/fstab), and then limiting the
compatibility entries that devfsd creates.

IF YOU CONFIGURE TO MOUNT DEVFS AT BOOT, MAKE SURE YOU INSTALL DEVFSD
BEFORE YOU BOOT A DEVFS-ENABLED KERNEL!

Now that devfs has gone into the 2.3.46 kernel, I'm getting a lot of
reports back. Many of these are because people are trying to run
without devfsd, and hence some things break. Please just run devfsd if
things break. I want to concentrate on real bugs rather than
misconfiguration problems at the moment. If people are willing to fix
bugs/false assumptions in other code (i.e. glibc, X server) and submit
that to the respective maintainers, that would be great.


All the way with Devfs

The devfs kernel patch creates a rationalised device tree. As stated
above, if you want to keep using the old /dev naming scheme,
you just need to configure devfsd appopriately (see the man
page). People who prefer the old names can ignore this section. For
those of us who like the rationalised names and an uncluttered
/dev, read on.

If you don't run devfsd, or don't enable compatibility entry
management, then you will have to configure your system to use the new
names. For example, you will then need to edit your
/etc/fstab to use the new disc naming scheme. If you want to
be able to boot non-devfs kernels, you will need compatibility
symlinks in the underlying disc-based /dev pointing back to
the old-style names for when you boot a kernel without devfs.

You can selectively decide which devices you want compatibility
entries for. For example, you may only want compatibility entries for
BSD pseudo-terminal devices (otherwise you'll have to patch you C
library or use Unix98 ptys instead). It's just a matter of putting in
the correct regular expression into /dev/devfsd.conf.

There are other choices of naming schemes that you may prefer. For
example, I don't use the kernel-supplied
names, because they are too verbose. A common misconception is
that the kernel-supplied names are meant to be used directly in
configuration files. This is not the case. They are designed to
reflect the layout of the devices attached and to provide easy
classification.

If you like the kernel-supplied names, that's fine. If you don't then
you should be using devfsd to construct a namespace more to your
liking. Devfsd has built-in code to construct a
namespace that is both logical and easy to
manage. In essence, it creates a convenient abbreviation of the
kernel-supplied namespace.

You are of course free to build your own namespace. Devfsd has all the
infrastructure required to make this easy for you. All you need do is
write a script. You can even write some C code and devfsd can load the
shared object as a callable extension.


Other Issues

The init programme
Another thing to take note of is whether your init programme
creates a Unix socket /dev/telinit. Some versions of init
create /dev/telinit so that the telinit programme can
communicate with the init process. If you have such a system you need
to make sure that devfs is mounted over /dev *before* init
starts. In other words, you can't leave the mounting of devfs to
/etc/rc, since this is executed after init. Other
versions of init require a named pipe /dev/initctl
which must exist *before* init starts. Once again, you need to
mount devfs and then create the named pipe *before* init
starts.

The default behaviour now is not to mount devfs onto /dev at
boot time for 2.3.x and later kernels. You can correct this with the
"devfs=mount" boot option. This solves any problems with init,
and also prevents the dreaded:

Cannot open initial console

message. For 2.2.x kernels where you need to apply the devfs patch,
the default is to mount.

If you have automatic mounting of devfs onto /dev then you
may need to create /dev/initctl in your boot scripts. The
following lines should suffice:

mknod /dev/initctl p
kill -SIGUSR1 1       # tell init that /dev/initctl now exists

Alternatively, if you don't want the kernel to mount devfs onto
/dev then you could use the following procedure is a
guideline for how to get around /dev/initctl problems:

# cd /sbin
# mv init init.real
# cat > init
#! /bin/sh
mount -n -t devfs none /dev
mknod /dev/initctl p
exec /sbin/init.real $*
[control-D]
# chmod a+x init

Note that newer versions of init create /dev/initctl
automatically, so you don't have to worry about this.

Module autoloading
You will need to configure devfsd to enable module
autoloading. The following lines should be placed in your
/etc/devfsd.conf file:

LOOKUP	.*		MODLOAD


As of devfsd-v1.3.10, a generic /etc/modules.devfs
configuration file is installed, which is used by the MODLOAD
action. This should be sufficient for most configurations. If you
require further configuration, edit your /etc/modules.conf
file. The way module autoloading work with devfs is:


a process attempts to lookup a device node (e.g. /dev/fred)


if that device node does not exist, the full pathname is passed to
devfsd as a string


devfsd will pass the string to the modprobe programme (provided the
configuration line shown above is present), and specifies that
/etc/modules.devfs is the configuration file


/etc/modules.devfs includes /etc/modules.conf to
access local configurations

modprobe will search it's configuration files, looking for an alias
that translates the pathname into a module name


the translated pathname is then used to load the module.


If you wanted a lookup of /dev/fred to load the
mymod module, you would require the following configuration
line in /etc/modules.conf:

alias    /dev/fred    mymod

The /etc/modules.devfs configuration file provides many such
aliases for standard device names. If you look closely at this file,
you will note that some modules require multiple alias configuration
lines. This is required to support module autoloading for old and new
device names.

Mounting root off a devfs device
If you wish to mount root off a devfs device when you pass the
"devfs=only" boot option, then you need to pass in the
"root=<device>" option to the kernel when booting. If you use
LILO, then you must have this in lilo.conf:

append = "root=<device>"

Surprised? Yep, so was I. It turns out if you have (as most people
do):

root = <device>


then LILO will determine the device number of <device> and will
write that device number into a special place in the kernel image
before starting the kernel, and the kernel will use that device number
to mount the root filesystem. So, using the "append" variety ensures
that LILO passes the root filesystem device as a string, which devfs
can then use.

Note that this isn't an issue if you don't pass "devfs=only".

TTY issues
The ttyname(3) function in some versions of the C library makes
false assumptions about device entries which are symbolic links.  The
tty(1) programme is one that depends on this function.  I've
written a patch to libc 5.4.43 which fixes this. This has been
included in libc 5.4.44 and a similar fix is in glibc 2.1.3.


Kernel Naming Scheme

The kernel provides a default naming scheme. This scheme is designed
to make it easy to search for specific devices or device types, and to
view the available devices. Some device types (such as hard discs),
have a directory of entries, making it easy to see what devices of
that class are available. Often, the entries are symbolic links into a
directory tree that reflects the topology of available devices. The
topological tree is useful for finding how your devices are arranged.

Below is a list of the naming schemes for the most common drivers. A
list of reserved device names is
available for reference. Please send email to
[e-mail] to obtain an allocation. Please be
patient (the maintainer is busy). An alternative name may be allocated
instead of the requested name, at the discretion of the maintainer.

Disc Devices

All discs, whether SCSI, IDE or whatever, are placed under the
/dev/discs hierarchy:

	/dev/discs/disc0	first disc
	/dev/discs/disc1	second disc


Each of these entries is a symbolic link to the directory for that
device. The device directory contains:

	disc	for the whole disc
	part*	for individual partitions


CD-ROM Devices

All CD-ROMs, whether SCSI, IDE or whatever, are placed under the