patch-2.3.46 linux/Documentation/filesystems/devfs/README
Next file: linux/Documentation/filesystems/devfs/ToDo
Previous file: linux/Documentation/filesystems/devfs/ChangeLog
Back to the patch index
Back to the overall index
- Lines: 854
- Date:
Wed Feb 16 15:42:05 2000
- Orig file:
v2.3.45/linux/Documentation/filesystems/devfs/README
- Orig date:
Wed Dec 31 16:00:00 1969
diff -u --recursive --new-file v2.3.45/linux/Documentation/filesystems/devfs/README linux/Documentation/filesystems/devfs/README
@@ -0,0 +1,853 @@
+/* -*- auto-fill -*- */
+
+ Device File System (devfs) Overview
+
+ Richard Gooch <rgooch@atnf.csiro.au>
+
+ 11-NOV-1999
+
+
+Conventions used in this document <section>
+=================================
+
+Each section in this document will have the string "<section>" at the
+right-hand side of the section title. Each subsection will have
+"<subsection>" at the right-hand side. These strings are meant to make
+it easier to search through the document.
+
+NOTE that the master copy of this document is available online at:
+http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.txt
+
+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/
+
+
+What is it? <section>
+===========
+
+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
+the devfs automatically, with whatever default ownership and
+protection the driver specified.
+
+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 the 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. 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? <section>
+==========
+
+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.
+
+Major&minor allocation <subsection>
+----------------------
+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 <subsection>
+---------------
+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 <subsection>
+-----------
+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 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 (natually) has a uniform mechanism
+to provide this information: the device nodes themselves!
+
+Node to driver file_operations translation <subsection>
+------------------------------------------
+There is an important difference between the way disc-based c&b 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 the 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 <subsection>
+------------------------------------
+Right now /dev contains a list of conceivable devices, most of which I
+don't have. A devfs would only show those devices available on my
+system. This means that listing /dev would be a handy way of checking
+what devices were available.
+
+Major&minor size <subsection>
+----------------
+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 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.
+
+Read-only root filesystem <subsection>
+------------------------
+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 <subsection>
+------------------------
+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 <subsection>
+------------
+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.
+This could be solved with a secure user-space daemon which runs as
+root and does the actual creation of pty-pairs. Such a daemon would
+require modification to *every* programme that wants to use this new
+mechanism. It also slows down creation of pty-pairs.
+An alternative is to create a new open_pty() syscall which does much
+the same thing as the user-space daemon. Once again, this requires
+modifications to pty-handling programmes.
+The devfs solution allows a device driver to "tag" certain device
+files so that when an unopened device is opened, the ownerships are
+changed to the current euid and egid of the opening process, and the
+protections are changed to the default registered by the driver. When
+the device is closed ownership is set back to root and protections are
+set back to read-write for everybody. No programme need be changed.
+The devpts filesystem provides this auto-ownership feature for Unix98
+ptys. It doesn't support old-style pty devices, nor does it have all
+the other features of devfs.
+
+Intelligent device management <subsection>
+-----------------------------
+Devfs implements a simple yet powerful protocol for communication with
+a device management daemon (devfsd) which runs in user space. It is
+possible to send a message (either synchronously or asynchronously) to
+devfsd on any event, such as registration/unregistration of device
+entries, opening and closing devices, looking up inodes, scanning
+directories and more. This has many possibilities. Some of these are
+already implemented.
+See: http://www.atnf.csiro.au/~rgooch/linux/
+
+Device entry registration events can be used by devfsd to change
+permissions of newly-created device nodes. This is one mechanism to
+control device permissions.
+
+Device entry registration/unregistration events can be used to run
+programmes or scripts. This can be used to provide automatic mounting
+of filesystems when a new block device media is inserted into the
+drive.
+
+Asynchronous device open and close events can be used to implement
+clever permissions management. For example, the default permissions on
+/dev/dsp do not allow everybody to read from the device. This is
+sensible, as you don't want some remote user recording what you say at
+your console. However, the console user is also prevented from
+recording. This behaviour is not desirable. With asynchronous device
+open and close events, you can have devfsd run a programme or script
+when console devices are opened to change the ownerships for *other*
+device nodes (such as /dev/dsp). On closure, you can run a different
+script to restore permissions. An advantage of this scheme over
+modifying the C library tty handling is that this works even if your
+programme crashes (how many times have you seen the utmp database with
+lingering entries for non-existent logins?).
+
+Synchronous device open events can be used to perform intelligent
+device access protections. Before the device driver open() method is
+called, the daemon must first validate the open attempt, by running an
+external programme or script. This is far more flexible than access
+control lists, as access can be determined on the basis of other
+system conditions instead of just the UID and GID.
+
+Inode lookup events can be used to authenticate module autoload
+requests. Instead of using kmod directly, the event can be sent to
+devfsd which can implement an arbitrary authentication before loading
+the module itself.
+Inode lookup events can also be used to construct arbitrary
+namespaces, without having to resort to populating devfs with symlinks
+to devices that don't exist.
+
+Speculative Device Scanning <subsection>
+---------------------------
+Consider an application (like cdparanoia) that wants to find all
+CD-ROM devices on the system (SCSI, IDE and other types), whether or
+not their respective modules are loaded. The application must
+speculatively open certain device nodes (such as /dev/sr0 for the SCSI
+CD-ROMs) in order to make sure the module is loaded. This requires
+that all Linux distributions follow the standard device naming scheme
+(last time I looked RedHat did things differently). Devfs solves the
+naming problem.
+
+The same application also wants to see which devices are actually
+available on the system. With the existing system it needs to read the
+/dev directory and speculatively open each /dev/sr* device to
+determine if the device exists or not. With a large /dev this is an
+inefficient operation, especially if there are many /dev/sr* nodes. A
+solution like scsidev could reduce the number of /dev/sr* entries (but
+of course that also requires all that inefficient directory scanning).
+
+With devfs, the application can open the /dev/sr directory (which
+triggers the module autoloading if required), and proceed to read
+/dev/sr. Since only the available devices will have entries, there are
+no inefficencies in directory scanning or device openings.
+
+
+Who else does it? <section>
+=================
+
+FreeBSD-current now has a devfs implementation. Solaris 2 has a
+pseudo-devfs (something akin to scsidev but for all devices, with some
+unspecified kernel support). BeOS and Plan9 also have it. SGI's IRIX
+6.4 and above also have a device filesystem.
+
+While we shouldn't just automatically do something because others do
+it, we should not ignore the work of others either. FreeBSD has a lot
+of competent people working on it, so their opinion should not be
+blithely ignored.
+
+
+How it works <section>
+============
+
+Registering device entries <subsection>
+--------------------------
+For every entry (device node) in a devfs-based /dev a driver must call
+devfs_register(). This adds the name of the device entry, the
+file_operations structure pointer and a few other things to an
+internal table. Device entries may be added and removed at any
+time. When a device entry is registered, it automagically appears in
+any mounted devfs'.
+
+Inode lookup <subsection>
+------------
+When a lookup operation on an entry is performed and if there is no
+driver information for that entry devfs will attempt to call devfsd or
+kmod. If still no driver information can be found then a negative
+dentry is yielded and the next stage operation will be called by the
+VFS (such as create() or mknod() inode methods). If driver information
+can be found, an inode is created (if one does not exist already) and
+all is well.
+
+Manually creating device nodes <subsection>
+------------------------------
+The mknod() method allows you to create an ordinary named pipe in the
+devfs, or you can create a character or block special inode if one
+does not already exist. You may wish to create a character or block
+special inode so that you can set permissions and ownership. Later, if
+a device driver registers an entry with the same name, the
+permissions, ownership and times are retained. This is how you can set
+the protections on a device even before the driver is loaded. Once you
+create an inode it appears in the directory listing.
+
+Unregistering device entries <subsection>
+----------------------------
+A device driver calls devfs_unregister() to unregister an entry.
+
+Chroot() gaols <subsection>
+--------------
+The semantics of inode creation are different when the devfs is
+mounted with the "explicit" option. Now, when a device entry is
+registered, it will not appear until you use mknod() to create the
+device. It doesn't matter if you mknod() before or after the device is
+registered with devfs_register(). The purpose of this behaviour is to
+support chroot(2) gaols, where you want to mount a minimal devfs
+inside the gaol. Only the devices you specifically want to be
+available (through your mknod() setup) will be accessible.
+
+
+Persistence of ownership/permissions across reboots <section>
+===================================================
+
+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.
+
+Upon bootup, simply untar the previously created tarfile, and all your
+ownerships/permissions will be retained. For the paranoid, you can
+save your permissions periodically using a cron job.
+
+NOTE: 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).
+
+I've provided a script called "rc.devfs" in this directory which you
+can use to save and restore permissions.
+
+Alternatively, you can use the device management daemon (devfsd) to
+control the permissions of device nodes. This has the advantage of
+being able to store permissions for whole groups of devices with a
+single configuration entry, rather than one (tar) entry per device
+node. Devfsd also receives inode change events, so you could easily
+implement a simple permissions database.
+
+
+Installation during the transition phase <section>
+========================================
+
+Currently, not all device drivers in the kernel have been modified to
+use devfs. If you want to boot between kernels with and without devfs
+support, this section discusses some options. Either way is safe,
+although some people will have different preferences.
+
+Note that your old-style (i.e. node-based) chroot /gaol/dev
+directories which you manually created will still work, unless you
+pass the "devfs=only" boot option.
+
+Fail-safe Approach with devfs mounted on /dev <subsection>
+---------------------------------------------
+The default is for devfs to be mounted onto /dev at boot time.
+Device drivers which do not yet have devfs support will not
+automagically appear in the 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 loosing most functionality
+(i.e. loosing 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 the 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.
+
+Fail-safe Approach with real /dev inodes <subsection>
+----------------------------------------
+This method involves more work, and is no longer recommended now that
+a large number of drivers have devfs support. You will need to use the
+"devfs=nomount" boot option.
+
+Copy the contents of /dev to /devfs. Then remove entries in /dev
+which are now available in devfs and make them symbolic links to the
+entries in /devfs. Finally, edit your /etc/fstab or boot scripts so
+that devfs is mounted over /devfs on bootup. If devfs is supported,
+accessing devices supported by devfs will follow the symlinks to
+devfs. If devfs is not supported, accessing those same devices will
+follow the symlinks to /devfs which contains only old-style device
+nodes. Devices not supported by devfs will be found directly on /dev.
+Simple! You can also follow this principle for chroot gaols.
+
+I've provided a demonstration script called "mk-devlinks" in this
+directory which you can use to create symlinks in /dev and
+/devfs. Note that this script is out of date and should not be run
+without modification.
+
+
+All the way with Devfs <section>
+======================
+
+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.
+
+
+Other Issues <section>
+============
+
+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 to mount devfs onto /dev at boot time.
+You can disable this with the "devfs=nomount" boot option, but you can
+then get harmless but annoying messages about not being able to open
+an initial console.
+
+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.
+
+Using kmod (module autoloading) <subsection>
+-------------------------------
+Another thing to note is that if you are using kmod then you need to
+edit your /etc/modules.conf so that things work properly. You should
+include the sample modules.conf file in the
+Documentation/filesystems/devfs directory into your /etc/modules.conf
+to ensure correct operation.
+
+Mounting root off a devfs device <subsection>
+--------------------------------
+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 <subsection>
+----------
+You may replace your tty devices in /dev with symbolic links to /devfs
+however you will then find that programmes which depend on ttyname(3)
+will no longer work properly. The <tty> programme is a good
+example. I've written a patch to libc 5.4.43 which fixes this. This
+has been included in libc 5.4.44 and glibc 2.1.?
+
+
+Device drivers currently ported <section>
+===============================
+
+- All miscellaneous character devices support devfs (this is done
+ transparently through misc_register())
+
+- SCSI discs and generic hard discs
+
+- Character memory devices (null, zero, full and so on)
+ Thanks to C. Scott Ananian <cananian@alumni.princeton.edu>
+
+- Loop devices (/dev/loop?)
+
+- TTY devices (console, serial ports, terminals and pseudo-terminals)
+ Thanks to C. Scott Ananian <cananian@alumni.princeton.edu>
+
+- SCSI tapes (/dev/st*)
+
+- SCSI CD-ROMs (/dev/sr*)
+
+- SCSI generic devices (/dev/sg*)
+
+- RAMDISCS (/dev/ram?)
+
+- Meta Devices (/dev/md*)
+
+- Floppy discs (/dev/fd?*)
+
+- Parallel port printers (/dev/lp*)
+
+- Sound devices
+ Thanks to Eric Dumas <dumas@linux.eu.org> and
+ C. Scott Ananian <cananian@alumni.princeton.edu>
+
+- Joysticks (/dev/js*)
+
+- Sparc keyboard (/dev/kbd)
+
+- DSP56001 digital signal processor (/dev/dsp56k)
+
+- Apple Desktop Bus (/dev/adb)
+
+- Coda network file system (/dev/cfs*)
+
+- Virtual console capture devices (/dev/vcs*)
+ Thanks to Dennis Hou <smilax@mindmeld.yi.org>
+
+- Frame buffer devices (/dev/fb*)
+
+- Video capture devices (/dev/video? /dev/vbi?)
+
+
+Naming Scheme <section>
+=============
+
+Disc Devices <subsection>
+------------
+
+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 <subsection>
+--------------
+
+All CD-ROMs, whether SCSI, IDE or whatever, are placed under the
+/dev/cdroms hierarchy:
+ /dev/cdroms/cdrom0 first CD-ROM
+ /dev/cdroms/cdrom1 second CD-ROM
+
+Each of these entries is a symbolic link to the real device entry for
+that device.
+
+Tape Devices <subsection>
+------------
+
+All tapes, whether SCSI, IDE or whatever, are placed under the
+/dev/tapes hierarchy:
+ /dev/tapes/tape0 first tape
+ /dev/tapes/tape1 second tape
+
+Each of these entries is a symbolic link to the directory for that
+device. The device directory contains:
+ mt for mode 0
+ mtl for mode 1
+ mtm for mode 2
+ mta for mode 3
+ mtn for mode 0, no rewind
+ mtln for mode 1, no rewind
+ mtmn for mode 2, no rewind
+ mtan for mode 3, no rewind
+
+SCSI Devices <subsection>
+------------
+To uniquely identify any SCSI device requires the following
+information:
+ controller (host adapter)
+ bus (SCSI channel)
+ target (SCSI ID)
+ unit (Logical Unit Number)
+
+All SCSI devices are placed under /dev/scsi (assuming devfs is mounted
+on /dev). Hence, a SCSI device with the following parameters:
+c=1,b=2,t=3,u=4 would appear as:
+ /dev/scsi/host1/bus2/target3/lun4 device directory
+
+Inside this directory, a number of device entries may be created,
+depending on which SCSI device-type drivers were installed.
+
+See the section on the disc naming scheme to see what entries the SCSI
+disc driver creates.
+
+See the section on the tape naming scheme to see what entries the SCSI
+tape driver creates.
+
+The SCSI CD-ROM driver creates:
+ cd
+
+The SCSI generic driver creates:
+ generic
+
+IDE Devices <subsection>
+-----------
+To uniquely identify any IDE device requires the following
+information:
+ controller
+ bus (aka. primary/secondary)
+ target (aka. master/slave)
+ unit
+
+All IDE devices are placed under /dev/ide (assuming devfs is mounted
+on /dev), and uses a similar naming scheme to the SCSI subsystem.
+
+
+XT Hard Discs <subsection>
+-------------
+All XT discs are placed under /dev/xd (assuming devfs is mounted on
+/dev). The first XT disc has the directory /dev/xd/disc0
+
+TTY devices <subsection>
+-----------
+The tty devices now appear as:
+ New name Old-name Device Type
+ -------- -------- -----------
+ /dev/tts/{0,1,...} /dev/ttyS{0,1,...} Serial ports
+ /dev/cua/{0,1,...} /dev/cua{0,1,...} Call out devices
+ /dev/vc/{0,1,...} /dev/tty{1...63} Virtual consoles
+ /dev/pty/m{0,1,...} /dev/ptyp?? PTY masters
+ /dev/pty/s{0,1,...} /dev/ttyp?? PTY slaves
+
+RAMDISCS <subsection>
+--------
+The RAMDISCS are placed in their own directory, and are named thus:
+ /dev/rd/{0,1,2,...}
+
+Meta Devices <subsection>
+------------
+The meta devices are placed in their own directory, and are named
+thus:
+ /dev/md/{0,1,2,...}
+
+Floppy discs <subsection>
+------------
+Floppy discs are placed in the /dev/floppy directory.
+
+Loop devices <subsection>
+------------
+Loop devices are placed in the /dev/loop directory.
+
+Sound devices <subsection>
+-------------
+Sound devices are placed in the /dev/sound directory (audio,
+sequencer, ...).
+
+
+SCSI Host Probing Issues <section>
+========================
+
+Devfs allows you to identify SCSI discs based in part on SCSI host
+numbers. If you have only one SCSI host (card) in your computer, then
+clearly it will be given host number 0. Life is not always that easy
+is you have multiple SCSI hosts. Unfortunately, it can sometimes be
+difficult to guess what the probing order of SCSI hosts is. You need
+to know the probe order before you can use device names. To make this
+easy, there is a kernel boot parameter called "scsihosts". This allows
+you to specify the probe order for different types of SCSI hosts. The
+syntax of this parameter is:
+
+scsihosts=<name_1>:<name_2>:<name_3>:...:<name_n>
+
+where <name_1>,<name_2>,...,<name_n> are the names of drivers used in
+/proc filesystem. For example:
+
+ scsihosts=aha1542:ppa:aha1542::ncr53c7xx
+
+means that devices connected to
+- first aha1542 controller - will be c0b#t#u#
+- first parallel port ZIP - will be c1b#t#u#
+- second aha1542 controller - will be c2b#t#u#
+- first NCR53C7xx controller - will be c4b#t#u#
+- any extra controller - will be c5b#t#u#, c6b#t#u#, etc
+- if any of above controllers will not be found - the reserved names will
+ not be used by any other device.
+- c3b#t#u# names will never be used
+
+You can use ',' instead of ':' as the separator character if you
+wish.
+
+Note that this scheme does not address the SCSI host order if you have
+multiple cards of the same type (such as NCR53c8xx). In this case you
+need to use the driver-specific boot parameters to control this.
+
+
+Allocation of Device Numbers <section>
+============================
+
+Devfs allows you to write a driver which doesn't need to allocate a
+device number (major&minor numbers) for the internal operation of the
+kernel. However, there are a number of userspace programmes that use
+the device number as a unique handle for a device. An example is the
+<find> programme, which uses device numbers to determine whether an
+inode is on a different filesystem than another inode. The device
+number used is the one for the block device which a filesystem is
+using. To preserve compatibility with userspace programmes, block
+devices using devfs need to have unique device numbers allocated to
+them. Furthermore, POSIX specifies device numbers, so some kind of
+device number needs to be presented to userspace.
+
+The simplest option (especially when porting drivers to devfs) is to
+keep using the old major and minor numbers. Devfs will take whatever
+values are given for major&minor and pass them onto userspace.
+
+Alternatively, you can have devfs choose unique device numbers for
+you. When you register a character or block device using
+<devfs_register> you can provide the optional DEVFS_FL_AUTO_DEVNUM
+flag, which will then automatically allocate a unique device number
+(the allocation is separated for the character and block devices).
+This device number is a 16 bit number, so this leaves plenty of space
+for large numbers of discs and partitions. This scheme can also be
+used for character devices, in particular the tty devices, which are
+currently limited to 256 pseudo-ttys (this limits the total number of
+simultaneous xterms and remote logins). Note that the device number
+is limited to the range 36864-61439 (majors 144-239), in order to
+avoid any possible conflicts with existing official allocations.
+
+A final note on this scheme: since it doesn't increase the size of
+device numbers, there are no compatibility issues with userspace.
FUNET's LINUX-ADM group, linux-adm@nic.funet.fi
TCL-scripts by Sam Shen (who was at: slshen@lbl.gov)