patch-2.4.0-test3 linux/Documentation/filesystems/devfs/README

• Lines: 312
• Date: Wed Jul 5 21:36:49 2000
• Orig file: v2.4.0-test2/linux/Documentation/filesystems/devfs/README
• Orig date: Fri Jun 23 21:55:06 2000

diff -u --recursive --new-file v2.4.0-test2/linux/Documentation/filesystems/devfs/README linux/Documentation/filesystems/devfs/README
@@ -3,7 +3,7 @@
 
 Linux Devfs (Device File System) FAQ
 Richard Gooch
-14-JUN-2000
+3-JUL-2000
 
 -----------------------------------------------------------------------------
 
@@ -20,7 +20,8 @@
 
 NEWFLASH: The official 2.3.46 kernel has
 included the devfs patch. Future patches will be released which
-build on this.
+build on this. These patches are rolled into Linus' tree from time to
+time.
 
 A mailing list is available which you may subscribe to. Send
 email
@@ -99,11 +100,11 @@
 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 49
-bytes for each entry in the namespace (93 bytes if you access the
-inode). 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 ramdisc.
+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
@@ -497,6 +498,8 @@
 
 Chroot() gaols
 
+2.2.x kernels
+
 The semantics of inode creation are different when 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
@@ -506,6 +509,31 @@
 gaol. Only the devices you specifically want to be available (through
 your mknod() setup) will be accessible.
 
+2.4.x kernels
+
+As of kernel 2.3.99, the VFS has had the ability to rebind parts of
+the global filesystem namespace into another part of the namespace.
+This now works even at the leaf-node level, which means that
+individual files and device nodes may be bound into other parts of the
+namespace. This is like making links, but better, because it works
+across filesystems (unlike hard links) and works through chroot()
+gaols (unlike symbolic links).
+
+Because of these improvements to the VFS, the multi-mount capability
+in devfs is no longer needed. The administrator may create a minimal
+device tree inside a chroot(2) gaol by using VFS bindings. As this
+provides most of the features of the devfs multi-mount capability, I
+removed the multi-mount support code (after issuing an RFC). This
+yielded code size reductions and simplifications.
+
+If you want to construct a minimal chroot() gaol, the following
+command should suffice:
+
+mount -t bind /dev/null /gaol/dev/null
+
+
+Repeat for other device nodes you want to expose. Simple!
+
 -----------------------------------------------------------------------------
 
 
@@ -598,11 +626,11 @@
  # man 5 console.perms 
 
  # file classes -- these are regular expressions 
--=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9] 
-+=tty[0-9][0-9]* [0-9][0-9]* :[0-9]\.[0-9] :[0-9] 
+-<console>=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9] 
++<console>=tty[0-9][0-9]* [0-9][0-9]* :[0-9]\.[0-9] :[0-9] 
 
  # device classes -- these are shell-style globs 
- =/dev/fd[0-1]* 
+ <floppy>=/dev/fd[0-1]* 
 
 
 Disable devpts
@@ -692,6 +720,44 @@
 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
+
+
+create the /dev-state directory
+
+
+add the following lines near the very beginning of your boot
+scripts:
+
+mount -t bind /dev /dev-state
+mount -t devfs none /dev
+devfsd /dev
+
+
+
+add the following lines to your /etc/devfsd.conf file:
+
+REGISTER	.*		COPY	/dev-state/$devname $devpath
+CHANGE		.*		COPY	$devpath /dev-state/$devname
+CREATE		.*		COPY	$devpath /dev-state/$devname
+
+
+
+reboot.
+
+
+
+
 
 Dealing with drivers without devfs support
 
@@ -718,7 +784,7 @@
 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 should have the fix.
+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
@@ -742,18 +808,19 @@
 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.
+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.
+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
@@ -797,8 +864,8 @@
 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
+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:
 
@@ -807,16 +874,16 @@
 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:
+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:
+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
@@ -832,32 +899,31 @@
 automatically, so you don't have to worry about this.
 
 Module autoloading
-Another thing to note is that if you want to support module
-autoloading 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.
-
-You will also need to configure devfsd to enable module
+You will need to configure devfsd to enable module
 autoloading. The following lines should be placed in your
-/etc/devfsd.conf:
+/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.
+
 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="
 option to the kernel when booting. If you use LILO, then you must have
 this in lilo.conf:
 
-append = "root="
+append = "root=<device>"
 
 Surprised? Yep, so was I. It turns out if you have (as most people
 do):
 
-root = 
+root = <device>
 
 
 then LILO will determine the device number of  and will write
@@ -1144,10 +1210,10 @@
 you to specify the probe order for different types of SCSI hosts. The
 syntax of this parameter is:
 
-scsihosts=:::...:
+scsihosts=<name_1>:<name_2>:<name_3>:...:<name_n>
 
-where ,,..., are the names of drivers used in
-/proc filesystem. For example:
+where <name_1>,<name_2>,...,<name_n> are the names
+of drivers used in the /proc filesystem. For example:
 
     scsihosts=aha1542:ppa:aha1542::ncr53c7xx
 
@@ -1309,7 +1375,7 @@
 This is not a bug. Network devices have their own, completely separate
 namespace. They are accessed via socket(2) and
 setsockopt(2) calls, and thus require no device nodes. I have
-raised the possibilty of moving network devices in the device
+raised the possibilty of moving network devices into the device
 namespace, but have had no response.
 
 
@@ -1418,7 +1484,7 @@
 a ramdisc-based solution would take more kernel memory, since the
 backing store would be (at best) normal VFS inodes and dentries, which
 take 284 bytes and 112 bytes, respectively, for each entry. Compare
-that to 49 or 93 bytes for devfs
+that to 72 bytes for devfs
 
 
 
@@ -1438,7 +1504,7 @@
 
 simplying increasing the device number size is insufficient. Apart
 from causing a lot of pain, it doesn't solve the management issues
-with a /dev with thousands or more device nodes
+of a /dev with thousands or more device nodes
 
 
 ignoring the problem of a huge /dev will not make it go
@@ -1473,8 +1539,17 @@
 
 Douglas Gilbert has written yet another useful document at
 
-http://www.torque.net/scsi/linux_scsi_24 which
+http://www.torque.net/scsi/linux_scsi_24/ which
 discusses the Linux SCSI subsystem in 2.4.
+
+
+Johannes Erdfelt has started a discussion paper on Linux and
+hot-swap devices, describing what the requirements are for a scalable
+solution and how and why he's used devfs+devfsd. Note that this is an
+early draft only, available in plain text form at:
+
+http://johannes.erdfelt.com/hotswap.txt.
+Johannes has promised a HTML version will follow.