Merge with 2.4.0-test3-pre4.

6 files changed, 220 insertions, 46 deletions

diff --git a/Documentation/Configure.help b/Documentation/Configure.help
index edaa621b0..62f8788f9 100644
--- a/Documentation/Configure.help
+++ b/Documentation/Configure.help
@@ -6462,6 +6462,14 @@ CONFIG_IEEE1394_PCILYNX_LOCALRAM
 
   If unsure, say N.
 
+Support for non-IEEE1394 local ports
+CONFIG_IEEE1394_PCILYNX_PORTS
+  This option enables driver code to access the RAM, ROM and AUX ports
+  of the PCILynx through character devices in /dev.  If you don't know
+  what this is about then you won't need it.
+  
+  If unsure, say N.
+
 Adaptec AIC-5800 IEEE 1394 support
 CONFIG_IEEE1394_AIC5800
   Say Y here if you have a IEEE 1394 controller using the Adaptec
@@ -12458,10 +12466,15 @@ CONFIG_ACPI
   below, then ACPI has precedence in the sense that, if your hardware
   supports ACPI, it will be used and APM won't.
 
-  To compile this driver as a module ( = code which can be inserted in
-  and removed from the running kernel whenever you want), say M here
-  and read Documentation/modules.txt. The module will be called 
-  acpi.o.
+ACPI interpreter (EXPERIMENTAL)
+CONFIG_ACPI_INTERPRETER
+  If you say Y here, an ACPI interpreter will be included in your
+  kernel, eventually making the full range of ACPI features
+  available on systems that support ACPI.  Note, this option will
+  enlarge your kernel by about 120K.
+
+  The interpreter is currently experimental so only say Y if
+  you know what you are doing.
 
 Enter S1 for sleep (EXPERIMENTAL)
 CONFIG_ACPI_S1_SLEEP
diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl
index 5b687eb76..9ea1fabe7 100644
--- a/Documentation/DocBook/kernel-locking.tmpl
+++ b/Documentation/DocBook/kernel-locking.tmpl
@@ -947,8 +947,10 @@
      </listitem>
     </itemizedlist>
 
-    <function>printk()</function> can be called in
-    <emphasis>any</emphasis> context, interestingly enough.
+    <para>
+     <function>printk()</function> can be called in
+     <emphasis>any</emphasis> context, interestingly enough.
+    </para>
    </sect1>
 
    <sect1 id="sparc">
diff --git a/Documentation/fb/matroxfb.txt b/Documentation/fb/matroxfb.txt
index d79f6694f..2575ecf17 100644
--- a/Documentation/fb/matroxfb.txt
+++ b/Documentation/fb/matroxfb.txt
@@ -191,6 +191,10 @@ nocross4MB - pixel line must not cross 4MB boundary. It is default for
 	     limitations which do not allow this. But this option is
 	     incompatible with some (if not all yet released) versions of
 	     XF86_FBDev.
+dfp      - enables digital flat panel interface. This option is incompatible with
+           secondary (TV) output - if DFP is active, TV output must be
+	   inactive and vice versa. DFP always uses same timming as primary
+	   (monitor) output.
 vesa:X   - selects startup videomode. X is number from 0 to 0x1FF, see table
            above for detailed explanation. Default is 640x480x8bpp if driver
 	   has 8bpp support. Otherwise first available of 640x350x4bpp,
diff --git a/Documentation/filesystems/devfs/ChangeLog b/Documentation/filesystems/devfs/ChangeLog
index a96f6f09e..4d7ccfcb5 100644
--- a/Documentation/filesystems/devfs/ChangeLog
+++ b/Documentation/filesystems/devfs/ChangeLog
@@ -1576,3 +1576,19 @@ Work sponsored by SGI
 - Changed interface to <devfs_register>
 
 - Changed interface to <devfs_register_series>
+===============================================================================
+Changes for patch v173
+
+Work sponsored by SGI
+
+- Simplified interface to <devfs_mk_symlink>
+
+- Simplified interface to <devfs_mk_dir>
+
+- Simplified interface to <devfs_find_handle>
+===============================================================================
+Changes for patch v174
+
+Work sponsored by SGI
+
+- Updated README from master HTML file
diff --git a/Documentation/filesystems/devfs/README b/Documentation/filesystems/devfs/README
index b09c8fd9e..bb3e47e92 100644
--- a/Documentation/filesystems/devfs/README
+++ b/Documentation/filesystems/devfs/README
@@ -3,7 +3,7 @@ Devfs (Device File System) FAQ
 
 Linux Devfs (Device File System) FAQ
 Richard Gooch
-14-JUN-2000
+25-JUN-2000
 
 -----------------------------------------------------------------------------
 
@@ -20,7 +20,8 @@ http://www.atnf.csiro.au/~rgooch/linux/
 
 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 @@ 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 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 @@ A device driver calls devfs_unregister() to unregister an entry.
 
 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 @@ 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.
 
+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 @@ startx.
  # 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 @@ 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
+
+
+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 @@ 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 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 @@ 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.
+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 @@ 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
+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 @@ 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:
+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
@@ -852,7 +919,7 @@ If you wish to mount root off a devfs device when you pass the
 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):
@@ -1144,10 +1211,10 @@ 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=:::...:
+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 +1376,7 @@ Why don't my network devices appear in devfs?
 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 +1485,7 @@ proposal above to "solve" this
 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 +1505,7 @@ minor limitation
 
 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
diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt
index 82c007564..e3b91823a 100644
--- a/Documentation/kernel-docs.txt
+++ b/Documentation/kernel-docs.txt
@@ -130,7 +130,7 @@
        
      * Title: "Dynamic Kernels: Discovery"
        Author: Alessandro Rubini.
-       URL: http://www.ssc.com/lj/issue24/kk24.html
+       URL: http://www2.linuxjournal.com/lj-issues/issue24/1220.html
        Keywords: character driver, init_module, clean_up module,
        autodetection,
        mayor number, minor number, file operations, open(), close().
@@ -142,7 +142,7 @@
        
      * Title: "The Devil's in the Details"
        Author: Georg v. Zezschwitz and Alessandro Rubini.
-       URL: http://www.ssc.com/lj/issue25/kk25.html
+       URL: http://www2.linuxjournal.com/lj-issues/issue25/1221.html
        Keywords: read(), write(), select(), ioctl(), blocking/non
        blocking mode, interrupt handler.
        Description: Linux Journal Kernel Korner article. Here is it's
@@ -178,7 +178,7 @@
        
      * Title: "Network Buffers And Memory Management"
        Author: Alan Cox.
-       URL: http://www.ssc.com/lj/issue30/kk30.html
+       URL: http://www2.linuxjournal.com/lj-issues/issue30/1312.html
        Keywords: sk_buffs, network devices, protocol/link layer
        variables, network devices flags, transmit, receive,
        configuration, multicast.
@@ -406,6 +406,77 @@
        different". Freely redistributable under the conditions of the GNU
        General Public License.
        
+     * Title: "Porting Linux 2.0 Drivers To Linux 2.2: Changes and New
+       Features "
+       Author: Alan Cox.
+       URL: http://www.linux-mag.com/1999-05/gear_01.html
+       Keywords: ports, porting.
+       Description: Article from Linux Magazine on porting from 2.0 to
+       2.2 kernels.
+       
+     * Title: "Porting Device Drivers To Linux 2.2: part II"
+       Author: Alan Cox.
+       URL: http://www.linux-mag.com/1999-06/gear_01.html
+       Keywords: ports, porting.
+       Description: Second part on porting from 2.0 to 2.2 kernels.
+       
+     * Title: "How To Make Sure Your Driver Will Work On The Power
+       Macintosh"
+       Author: Paul Mackerras.
+       URL: http://www.linux-mag.com/1999-07/gear_01.html
+       Keywords: Mac, Power Macintosh, porting, drivers, compatibility.
+       Description: The title says it all.
+       
+     * Title: "An Introduction to SCSI Drivers"
+       Author: Alan Cox.
+       URL: http://www.linux-mag.com/1999-08/gear_01.html
+       Keywords: SCSI, device, driver.
+       Description: The title says it all.
+       
+     * Title: "Advanced SCSI Drivers And Other Tales"
+       Author: Alan Cox.
+       URL: http://www.linux-mag.com/1999-09/gear_01.html
+       Keywords: SCSI, device, driver, advanced.
+       Description: The title says it all.
+       
+     * Title: "Writing Linux Mouse Drivers"
+       Author: Alan Cox.
+       URL: http://www.linux-mag.com/1999-10/gear_01.html
+       Keywords: mouse, driver, gpm.
+       Description: The title says it all.
+       
+     * Title: "More on Mouse Drivers"
+       Author: Alan Cox.
+       URL: http://www.linux-mag.com/1999-11/gear_01.html
+       Keywords: mouse, driver, gpm, races, asynchronous I/O.
+       Description: The title still says it all.
+       
+     * Title: "Writing Video4linux Radio Driver"
+       Author: Alan Cox.
+       URL: http://www.linux-mag.com/1999-12/gear_01.html
+       Keywords: video4linux, driver, radio, radio devices.
+       Description: The title says it all.
+       
+     * Title: "Video4linux Drivers, Part 1: Video-Capture Device"
+       Author: Alan Cox.
+       URL: http://www.linux-mag.com/2000-01/gear_01.html
+       Keywords: video4linux, driver, video capture, capture devices,
+       camera driver.
+       Description: The title says it all.
+       
+     * Title: "Video4linux Drivers, Part 2: Video-capture Devices"
+       Author: Alan Cox.
+       URL: http://www.linux-mag.com/2000-02/gear_01.html
+       Keywords: video4linux, driver, video capture, capture devices,
+       camera driver, control, query capabilities, capability, facility.
+       Description: The title says it all.
+       
+     * Title: "PCI Management in Linux 2.2"
+       Author: Alan Cox.
+       URL: http://www.linux-mag.com/2000-03/gear_01.html
+       Keywords: PCI, bus, bus-mastering.
+       Description: The title says it all.
+       
      BOOKS: (Not on-line)
    
      * Title: "Linux Device Drivers"
@@ -475,7 +546,7 @@
        ISBN: 0-13-101908-2
        
      * Title: "Linux Core Kernel Commentary. Guide to Insider's Knowledge
-       on the Core Kernel od the Linux Code"
+       on the Core Kernel of the Linux Code"
        Author: Scott Maxwell.
        Publisher: Coriolis.
        Date: 1999.
@@ -598,9 +669,10 @@
      * Name: "linux-kernel mailing list archives and search engines"
        URL: http://www.uwsg.indiana.edu/hypermail/linux/kernel/index.html
        URL: http://www.kernelnotes.org/lnxlists/linux-kernel/
+       URL: http://www.geocrawler.com
        Keywords: linux-kernel, archives, search.
        Description: Some of the linux-kernel mailing list archivers. If
        you have a better/another one, please let me know.
      _________________________________________________________________
    
-   Document last updated on Mon Apr 17 18:07:07 CEST 2000
+   Document last updated on Thu Jun 1 21:58:18 CEST 2000DATE$