Import of Linux/MIPS 2.1.14

78 files changed, 22755 insertions, 0 deletions

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
new file mode 100644
index 000000000..1a6fb3b90
--- /dev/null
+++ b/Documentation/00-INDEX
@@ -0,0 +1,69 @@
+This is a brief list of all the files in ./linux/Documentation and what
+they contain. If you add a documentation file, please list it here in 
+alphabetical order as well. Note that subdirectories have their own
+index files too.
+							 Thanks -- Paul.
+
+00-INDEX
+	- this file.
+BUG-HUNTING
+	- brute force method of doing binary search of patches to find bug.
+Changes
+	- list of changes that break older software packages.
+CodingStyle
+	- how the boss likes the C code in the kernel to look.
+Configure.help
+	- text file that is used for help when you run "make config"
+SMP.txt
+	- notes, and "To Fix" list for multi-processor Linux. (see smp.tex)
+cdrom/
+	- directory with information on the CD-ROM drivers that Linux has.
+devices.tex
+	- TeX source listing of all the nodes in /dev/ with major minor #'s
+devices.txt
+	- plain ASCII listing of all the nodes in /dev/ with major minor #'s
+digiboard.txt
+	- info on the Digiboard PC/X{i,e,eve} multiport boards.
+filesystems/
+	- directory with info on the various filesystems that Linux supports.
+ide.txt
+	- important info for users of ATA devices (IDE/EIDE disks and CD-ROMS)
+initrd.txt
+	- how to use the RAM disk as an initial/temporary root filesystem.
+ioctl-number.txt
+	- how to implement and register device/driver ioctl calls.
+isdn/
+	- directory with info on the linux ISDN support, and supported cards.
+java.txt
+	- info on the in-kernel binary support for Java(tm)
+locks.txt
+	- info on file locking implementations, flock() vs. fcntl(), etc.
+magic-number.txt
+	- list of magic numbers used to mark/protect kernel data structures.
+mandatory.txt
+	- info on the linux implementation of Sys V mandatory file locking.
+modules.txt
+	- short guide on how to make kernel parts into loadable modules
+networking/
+	- directory with info on various linux networking aspects.
+nfsroot.txt
+	- short guide on setting up a diskless box with NFS root filesystem
+oops-tracing.txt
+	- how to decode those nasty internal kernel error dump messages.
+ramdisk.txt
+	- short guide on how to set up and use the RAM disk.
+riscom8.txt
+	- notes on using the RISCom/8 multi-port serial driver.
+rtc.txt
+	- notes on how to use the Real Time Clock (aka CMOS clock) driver.
+scsi.txt
+	- short blurb on using SCSI support as a module.
+smp.tex
+	- TeX document describing implementation of Multiprocessor Linux
+svga.txt
+	- short guide on selecting video modes at boot via VGA BIOS.
+unicode.txt
+	- info on the Unicode character/font mapping used in Linux.
+watchdog.txt
+	- how to auto-reboot Linux if it has "fallen and can't get up". ;-)
+
diff --git a/Documentation/BUG-HUNTING b/Documentation/BUG-HUNTING
new file mode 100644
index 000000000..fc7e0abd6
--- /dev/null
+++ b/Documentation/BUG-HUNTING
@@ -0,0 +1,92 @@
+[Sat Mar  2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)]
+
+This is how to track down a bug if you know nothing about kernel hacking.  
+It's a brute force approach but it works pretty well.
+
+You need:
+
+        . A reproducible bug - it has to happen predictably (sorry)
+        . All the kernel tar files from a revision that worked to the
+          revision that doesn't
+
+You will then do:
+
+        . Rebuild a revision that you believe works, install, and verify that.
+        . Do a binary search over the kernels to figure out which one
+          introduced the bug.  I.e., suppose 1.3.28 didn't have the bug, but 
+          you know that 1.3.69 does.  Pick a kernel in the middle and build
+          that, like 1.3.50.  Build & test; if it works, pick the mid point
+          between .50 and .69, else the mid point between .28 and .50.
+        . You'll narrow it down to the kernel that introduced the bug.  You
+          can probably do better than this but it gets tricky.  
+
+        . Narrow it down to a subdirectory
+
+          - Copy kernel that works into "test".  Let's say that 3.62 works,
+            but 3.63 doesn't.  So you diff -r those two kernels and come
+            up with a list of directories that changed.  For each of those
+            directories:
+
+                Copy the non-working directory next to the working directory
+                as "dir.63".  
+                One directory at time, try moving the working directory to
+                "dir.62" and mv dir.63 dir"time, try 
+
+                        mv dir dir.62
+                        mv dir.63 dir
+                        find dir -name '*.[oa]' -print | xargs rm -f
+
+                And then rebuild and retest.  Assuming that all related
+                changes were contained in the sub directory, this should 
+                isolate the change to a directory.  
+
+                Problems: changes in header files may have occurred; I've
+                found in my case that they were self explanatory - you may 
+                or may not want to give up when that happens.
+
+        . Narrow it down to a file
+
+          - You can apply the same technique to each file in the directory,
+            hoping that the changes in that file are self contained.  
+            
+        . Narrow it down to a routine
+
+          - You can take the old file and the new file and manually create
+            a merged file that has
+
+                #ifdef VER62
+                routine()
+                {
+                        ...
+                }
+                #else
+                routine()
+                {
+                        ...
+                }
+                #endif
+
+            And then walk through that file, one routine at a time and
+            prefix it with
+
+                #define VER62
+                /* both routines here */
+                #undef VER62
+
+            Then recompile, retest, move the ifdefs until you find the one
+            that makes the difference.
+
+Finally, you take all the info that you have, kernel revisions, bug
+description, the extent to which you have narrowed it down, and pass 
+that off to whomever you believe is the maintainer of that section.
+A post to linux.dev.kernel isn't such a bad idea if you've done some
+work to narrow it down.
+
+If you get it down to a routine, you'll probably get a fix in 24 hours.
+
+My apologies to Linus and the other kernel hackers for describing this
+brute force approach, it's hardly what a kernel hack would do.  However,
+it does work and it lets non-hackers help bug fix.  And it is cool
+because Linux snapshots will let you do this - something that you can't
+do with vender supplied releases.
+
diff --git a/Documentation/Changes b/Documentation/Changes
new file mode 100644
index 000000000..66a0b416c
--- /dev/null
+++ b/Documentation/Changes
@@ -0,0 +1,181 @@
+Intro
+=====
+
+This document is designed to provide a list of the minimum levels of
+software necessary to run the 2.1.x kernels, as well as provide brief
+instructions regarding any other "Gotchas" users may encounter when
+trying life on the Bleeding Edge.  If upgrading from a pre-2.0.x
+kernel, please consult the Changes file included with 2.0.x kernels for
+additional information; most of that information will not be repeated
+here.  Basically, this document assumes that your system is already
+functional and running at least 2.0.x.
+
+   It is originally based on my "Changes" file for 2.0.x kernels and
+therefore owes credit to the same people as that file (Jared Mauch,
+Axel Boldt, Alessandro Sigala, and countless other users all over the
+'net).  Please feel free to submit changes, corrections, gripes,
+flames, money, etc. to me (gt1355b@prism.gatech.edu).  If you do so,
+you don't need to bother doing so in the form of a diff, as this is
+generated by texinfo so a diff is useless anyway (though I can
+incorporate one by hand if you insist upon sending it that way ;-).
+
+Last updated: November 20, 1996.
+Current Author: Chris Ricker (gt1355b@prism.gatech.edu).
+
+Current Minimal Requirements
+****************************
+
+   Upgrade to at *least* these software revisions before thinking you've
+encountered a bug!
+
+- Kernel modules	 2.0.8
+- Gnu C 		 2.7.2.1
+- Binutils		 2.7.0.3
+- Linux C Library	 5.4.12
+- Dynamic Linker (ld.so) 1.8.5
+- Linux C++ Library	 2.7.2.1
+- Procps		 1.01
+- SysVinit		 2.64
+- Mount                  2.5p
+- Net-tools              1.32-alpha
+- Kbd                    0.91
+
+Upgrade notes
+*************
+
+General Information
+===================
+
+   <CTRL><ALT><DEL> now performs a cold reboot instead of a warm reboot
+for increased hardware compatibility.  If you want a warm reboot and
+know it works on your hardware, add a "reboot=warm" command line option
+in Lilo.
+
+Libc
+====
+
+   Linux-2.1.x is ELF-only.  You can still compile a.out apps if you
+really want, but your kernel must be compiled ELF.  If you can't
+currently compile ELF, consult the ELF howto at
+http://sunsite.unc.edu/mdw/HOWTO/ELF-HOWTO.html and upgrade your system
+accordingly.
+
+   For modules to work, you need to be running libc-5.4.7 or greater.
+Since updates to libc fix other problems as well (security flaws, for
+example) and since 5.4.7 is missing a few needed symbols, try to get
+the latest 5.4.x you can.  Currently, that is libc-5.4.12.
+
+   If you upgrade to libc-5.4.x, you also have to upgrade your dynamic
+linker (ld.so) to at least 1.8.3, or all sorts of weirdness will happen.
+
+Modules
+=======
+
+   You need to upgrade to modules-2.0.8 for kernels 2.1.8 and later.
+Currently, there is no modules package which works with kernel 2.1.1.
+
+Gnu C
+=====
+
+   You need at least GCC 2.7.2 to compile the kernel.  If you're
+upgrading from an earlier release, you might as well get GCC 2.7.2.1,
+the latest public release.  If you already have GCC 2.7.2 on your
+system, you don't have to upgrade just so the kernel will work (though
+feel free to upgrade if you want the gcc bug fixes).
+
+How to know the version of the installed programs
+*************************************************
+
+   There are some simple methods useful to know the version of the
+installed programs and libraries.  The SysVinit version display
+requires that you be logged in as root.
+
+Gnu C: gcc -v or gcc --version
+Libc: ls -l /lib/libc.so.*
+Libc++: ls -l /usr/lib/libg++.so.*
+Binutils: ld -v
+modules: insmod -V
+procps: ps --version
+SysVinit: cat /proc/`cat /var/run/syslog.pid`/environ|strings|awk '$1 ~
+/INIT_VERSION/ {print}'
+
+Where to get the files
+**********************
+
+Binutils
+========
+
+ftp://tsx-11.mit.edu:/pub/linux/packages/GCC/binutils-2.7.0.3.bin.tar.gz
+Installation notes:
+ftp://tsx-11.mit.edu:/pub/linux/packages/GCC/release.binutils-2.7.0.3
+
+Gnu C
+=====
+
+ftp://sunsite.unc.edu/pub/Linux/GCC/gcc-2.7.2.1.bin.tar.gz
+Installation notes:
+ftp://sunsite.unc.edu/pub/Linux/GCC/release.gcc-2.7.2.1
+
+Linux C Library
+===============
+
+The stable 5.2.18 release:
+ftp://sunsite.unc.edu/pub/Linux/GCC/libc-5.2.18.bin.tar.gz
+Installation notes for 5.2.18:
+ftp://sunsite.unc.edu/pub/Linux/GCC/release.libc-5.2.18
+
+The latest 5.4.12 release (when it gets there):
+ftp://sunsite.unc.edu/pub/Linux/GCC/libc-5.4.12.bin.tar.gz
+Installation notes for 5.4.12:
+ftp://sunsite.unc.edu/pub/Linux/GCC/release.libc-5.4.12
+
+Linux C++ Library
+=================
+
+ftp://sunsite.unc.edu/pub/Linux/GCC/libg++-2.7.2.1.bin.tar.gz
+Installation notes:
+ftp://sunsite.unc.edu/pub/Linux/GCC/release.libg++-2.7.2.1
+
+Dynamic Linker
+==============
+
+ftp://sunsite.unc.edu/pub/Linux/GCC/ld.so-1.8.5.tar.gz
+
+Modules utilities
+=================
+
+ftp://sunsite.unc.edu/pub/Linux/kernel/v2.1/modules-2.0.8.tar.gz
+
+Procps utilities
+================
+
+ftp://sunsite.unc.edu/pub/Linux/system/Status/ps/procps-1.01.tgz
+
+SysVinit utilities
+==================
+
+ftp://sunsite.unc.edu/pub/Linux/system/Daemons/init/sysvinit-2.64.tar.gz
+
+Other Info
+==========
+
+   Please remember that most of these utils are available on your
+favorite local linux mirror.  If you can, please get them from a closer
+site before checking sunsite.
+
+   Also, for those of you running Red Hat (or RPM on a different
+distribution), most of these are available in RPM format.  Check around
+your favorite Red Hat mirror site before installing the non-RPM
+version.  Remember, you might need to use the -force option to get the
+upgrade to install.  ftp://ftp.redhat.com/pub/contrib/ will have almost
+everything you need.
+
+   For others, David Bourgin has put together a package of everything
+necessary to quickly and easily upgrade to 2.1.x.  See
+ftp://ftp.wsc.com/pub/freeware/linux/update.linux/kernel-v2.1.x/ for
+more information and the files.
+
+Please send info about any other packages that 2.1.x "broke" or about
+any new features of 2.1.x that require extra or new packages for use to
+Chris Ricker (gt1355b@prism.gatech.edu).
+
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
new file mode 100644
index 000000000..7d72179f7
--- /dev/null
+++ b/Documentation/CodingStyle
@@ -0,0 +1,212 @@
+
+		Linux kernel coding style 
+
+This is a short document describing the preferred coding style for the
+linux kernel.  Coding style is very personal, and I won't _force_ my
+views on anybody, but this is what goes for anything that I have to be
+able to maintain, and I'd prefer it for most other things too.  Please
+at least consider the points made here. 
+
+First off, I'd suggest printing out a copy of the GNU coding standards,
+and NOT read it.  Burn them, it's a great symbolic gesture. 
+
+Anyway, here goes:
+
+
+	 	Chapter 1: Indentation
+
+Tabs are 8 characters, and thus indentations are also 8 characters. 
+There are heretic movements that try to make indentations 4 (or even 2!)
+characters deep, and that is akin to trying to define the value of PI to
+be 3. 
+
+Rationale: The whole idea behind indentation is to clearly define where
+a block of control starts and ends.  Especially when you've been looking
+at your screen for 20 straight hours, you'll find it a lot easier to see
+how the indentation works if you have large indentations. 
+
+Now, some people will claim that having 8-character indentations makes
+the code move too far to the right, and makes it hard to read on a
+80-character terminal screen.  The answer to that is that if you need
+more than 3 levels of indentation, you're screwed anyway, and should fix
+your program. 
+
+In short, 8-char indents make things easier to read, and have the added
+benefit of warning you when you're nesting your functions too deep. 
+Heed that warning. 
+
+
+		Chapter 2: Placing Braces
+
+The other issue that always comes up in C styling is the placement of
+braces.  Unlike the indent size, there are few technical reasons to
+choose one placement strategy over the other, but the preferred way, as
+shown to us by the prophets Kernighan and Ritchie, is to put the opening
+brace last on the line, and put the closing brace first, thusly:
+
+	if (x is true) {
+		we do y
+	}
+
+However, there is one special case, namely functions: they have the
+opening brace at the beginning of the next line, thus:
+
+	int function(int x)
+	{
+		body of function
+	}
+
+Heretic people all over the world have claimed that this inconsistency
+is ...  well ...  inconsistent, but all right-thinking people know that
+(a) K&R are _right_ and (b) K&R are right.  Besides, functions are
+special anyway (you can't nest them in C). 
+
+Note that the closing brace is empty on a line of its own, _except_ in
+the cases where it is followed by a continuation of the same statement,
+ie a "while" in a do-statement or an "else" in an if-statement, like
+this:
+
+	do {
+		body of do-loop
+	} while (condition);
+
+and
+
+	if (x == y) {
+		..
+	} else if (x > y) {
+		...
+	} else {
+		....
+	}
+			
+Rationale: K&R. 
+
+Also, note that this brace-placement also minimizes the number of empty
+(or almost empty) lines, without any loss of readability.  Thus, as the
+supply of new-lines on your screen is not a renewable resource (think
+25-line terminal screens here), you have more empty lines to put
+comments on. 
+
+
+		Chapter 3: Naming
+
+C is a Spartan language, and so should your naming be.  Unlike Modula-2
+and Pascal programmers, C programmers do not use cute names like
+ThisVariableIsATemporaryCounter.  A C programmer would call that
+variable "tmp", which is much easier to write, and not the least more
+difficult to understand. 
+
+HOWEVER, while mixed-case names are frowned upon, descriptive names for
+global variables are a must.  To call a global function "foo" is a
+shooting offense. 
+
+GLOBAL variables (to be used only if you _really_ need them) need to
+have descriptive names, as do global functions.  If you have a function
+that counts the number of active users, you should call that
+"count_active_users()" or similar, you should _not_ call it "cntusr()". 
+
+Encoding the type of a function into the name (so-called Hungarian
+notation) is brain damaged - the compiler knows the types anyway and can
+check those, and it only confuses the programmer.  No wonder MicroSoft
+makes buggy programs. 
+
+LOCAL variable names should be short, and to the point.  If you have
+some random integer loop counter, it should probably be called "i". 
+Calling it "loop_counter" is non-productive, if there is no chance of it
+being mis-understood.  Similarly, "tmp" can be just about any type of
+variable that is used to hold a temporary value. 
+
+If you are afraid to mix up your local variable names, you have another
+problem, which is called the function-growth-hormone-imbalance syndrome. 
+See next chapter. 
+
+		
+		Chapter 4: Functions
+
+Functions should be short and sweet, and do just one thing.  They should
+fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
+as we all know), and do one thing and do that well. 
+
+The maximum length of a function is inversely proportional to the
+complexity and indentation level of that function.  So, if you have a
+conceptually simple function that is just one long (but simple)
+case-statement, where you have to do lots of small things for a lot of
+different cases, it's ok to have a longer function. 
+
+However, if you have a complex function, and you suspect that a
+less-than-gifted first-year high-school student might not even
+understand what the function is all about, you should adhere to the
+maximum limits all the more closely.  Use helper functions with
+descriptive names (you can ask the compiler to in-line them if you think
+it's performance-critical, and it will probably do a better job of it
+that you would have done). 
+
+Another measure of the function is the number of local variables.  They
+shouldn't exceed 5-10, or you're doing something wrong.  Re-think the
+function, and split it into smaller pieces.  A human brain can
+generally easily keep track of about 7 different things, anything more
+and it gets confused.  You know you're brilliant, but maybe you'd like
+to understand what you did 2 weeks from now. 
+
+
+		Chapter 5: Commenting
+
+Comments are good, but there is also a danger of over-commenting.  NEVER
+try to explain HOW your code works in a comment: it's much better to
+write the code so that the _working_ is obvious, and it's a waste of
+time to explain badly written code. 
+
+Generally, you want your comments to tell WHAT your code does, not HOW. 
+Also, try to avoid putting comments inside a function body: if the
+function is so complex that you need to separately comment parts of it,
+you should probably go back to chapter 4 for a while.  You can make
+small comments to note or warn about something particularly clever (or
+ugly), but try to avoid excess.  Instead, put the comments at the head
+of the function, telling people what it does, and possibly WHY it does
+it. 
+
+
+		Chapter 6: You've made a mess of it
+
+That's ok, we all do.  You've probably been told by your long-time unix
+user helper that "GNU emacs" automatically formats the C sources for
+you, and you've noticed that yes, it does do that, but the defaults it
+uses are less than desirable (in fact, they are worse than random
+typing - a infinite number of monkeys typing into GNU emacs would never
+make a good program). 
+
+So, you can either get rid of GNU emacs, or change it to use saner
+values.  To do the latter, you can stick the following in your .emacs file:
+
+(defun linux-c-mode ()
+  "C mode with adjusted defaults for use with the Linux kernel."
+  (interactive)
+  (c-mode)
+  (c-set-style "K&R")
+  (setq c-basic-offset 8))
+
+This will define the M-x linux-c-mode command.  When hacking on a
+module, if you put the string -*- linux-c -*- somewhere on the first
+two lines, this mode will be automatically invoked. Also, you may want
+to add
+
+(setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode)
+                       auto-mode-alist))
+
+to your .emacs file if you want to have linux-c-mode switched on
+automagically when you edit source files under /usr/src/linux.
+
+But even if you fail in getting emacs to do sane formatting, not
+everything is lost: use "indent".
+
+Now, again, GNU indent has the same brain dead settings that GNU emacs
+has, which is why you need to give it a few command line options. 
+However, that's not too bad, because even the makers of GNU indent
+recognize the authority of K&R (the GNU people aren't evil, they are
+just severely misguided in this matter), so you just give indent the
+options "-kr -i8" (stands for "K&R, 8 character indents"). 
+
+"indent" has a lot of options, and especially when it comes to comment
+re-formatting you may want to take a look at the manual page.  But
+remember: "indent" is not a fix for bad programming. 
diff --git a/Documentation/Configure.help b/Documentation/Configure.help
new file mode 100644
index 000000000..cc97ae57d
--- /dev/null
+++ b/Documentation/Configure.help
@@ -0,0 +1,3927 @@
+# Maintained by Axel Boldt (boldt@math.ucsb.edu) 
+#
+# This version of the Linux kernel configuration help texts
+# corresponds to the kernel versions 2.1.x.
+#
+# International versions of this file available on the WWW:
+#   - http://jf.gee.kyoto-u.ac.jp/JF/JF-ftp/euc/Configure.help.euc
+# is a Japanese translation, maintained by Tetsuyasu YAMADA
+# (tetsu@cauchy.nslab.ntt.jp). 
+#   - http://nevod.perm.su/service/linux/doc/kernel/Configure.help 
+# is a Russian translation, maintained by kaf@linux.nevod.perm.su.
+#
+# Information about what a kernel is, what it does, how to patch and
+# compile it and much more is contained in the Kernel-HOWTO, available
+# via ftp (user: anonymous) from sunsite.unc.edu in the directory
+# /pub/Linux/docs/HOWTO. 
+#
+# Format of this file: description<nl>variable<nl>helptext<nl><nl>. 
+# If the question being documented is of type "choice", we list
+# only the first occurring config variable. The help texts
+# must not contain empty lines. No variable should occur twice; if it
+# does, only the first occurrence will be used by Configure. The lines
+# in a help text should be indented two positions. Lines starting with
+# `#' are ignored. To be nice to menuconfig, limit your lines to 70
+# characters. Use emacs' kfill.el to edit this file or you lose.
+#
+# If you add a help text to this file, please try to be as gentle as
+# possible. Don't use unexplained acronyms and generally write for the
+# hypothetical user who has just bought a PC, removed Windows,
+# installed Linux and is now recompiling the kernel for the first
+# time. Tell them what to do if they're unsure. Technical information
+# should go in a README in the Documentation directory. Mention all 
+# the relevant READMEs and HOWTOs in the help text.
+#
+# All this was shamelessly stolen from several different sources. Many
+# thanks to all the contributors.  Feel free to use these help texts
+# in your own kernel configuration tools. The texts are copyrighted
+# (c) 1995,1996 by Axel Boldt and governed by the GNU Public License.
+
+Prompt for development and/or incomplete code/drivers
+CONFIG_EXPERIMENTAL
+  Some of the various things that Linux supports (such as network 
+  drivers, filesystems, network protocols, etc.) can be in a state 
+  of development where the functionality, stability, or the level of 
+  testing is not yet high enough for general use. This is usually
+  known as the "alpha-test" phase amongst developers. If a feature is
+  currently in alpha-test, then the developers usually discourage 
+  uninformed widespread use of this feature by the general public to
+  avoid "Why doesn't this work?" type mail messages. However, active
+  testing and use of these systems is welcomed. Just be aware that it
+  may not meet the normal level of reliability or it may fail to work
+  in some special cases. Detailed bug reports from people familiar with
+  the kernel internals are usually welcomed by the developers. 
+  Unless you intend to help test and develop a feature or driver that
+  falls into this category, or you have a situation that requires using 
+  these features you should probably say N here, which will cause this 
+  configure script to present you with fewer choices. If you say Y here,
+  you will be offered the choice of using features or drivers that are
+  currently considered to be in the alpha-test phase.
+
+Kernel math emulation
+CONFIG_MATH_EMULATION
+  Linux can emulate a math coprocessor (used for floating point
+  operations) if you don't have one. 486DX and Pentium processors have
+  a math coprocessor built in, 486SX and 386 do not, unless you added
+  a 487DX or 387, respectively.  (The messages during boot time can
+  give you some hints here ["man dmesg"]) Everyone needs either a
+  coprocessor or this emulation. If you enable this emulation even
+  though you have a coprocessor, the coprocessor will be used
+  nevertheless. (This behavior can be changed with the kernel command
+  line option "no387", which comes handy if your coprocessor is
+  broken. See the documentation of your boot loader (lilo or loadlin)
+  about how to pass options to the kernel at boot time. The lilo
+  procedure is also explained in the SCSI-HOWTO, available via ftp
+  (user: anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO.) This
+  means that it is a good idea to say Y here if you intend to use this
+  kernel on different machines. More information about the internals
+  of Linux math coprocessor emulation can be found in
+  arch/i386/math-emu/README. If you are not sure, say Y; apart from
+  resulting in a 45kB bigger kernel, it won't hurt.
+
+Normal floppy disk support
+CONFIG_BLK_DEV_FD
+  If you want to use your floppy disk drive(s) under Linux, say
+  Y. Information about this driver, especially important for IBM
+  Thinkpad users, is contained in drivers/block/README.fd.  This
+  driver is also available as a module ( = code which can be inserted
+  in and removed from the running kernel whenever you want). If you
+  want to compile it as a module, say M here and read
+  Documentation/modules.txt.
+  
+RAM disk support
+CONFIG_BLK_DEV_RAM
+  Enabling this option will allow you to use a portion of your RAM
+  memory as a block device, so that you can make filesystems on it,
+  read and write to it and do all the other things that normal block
+  devices (such as harddrives) can do.  It is usually used to load and
+  store a copy of a minimal root file system off of a floppy into RAM
+  during the initial install of Linux.  Note that the kernel command
+  line option "ramdisk=XX" is now obsolete.  For details, read
+  Documentation/ramdisk.txt. If you want to compile this as a module (
+  = code which can be inserted in and removed from the running kernel
+  whenever you want), say M and read Documentation/modules.txt.  Most
+  normal users won't need the RAM disk functionality, and can thus say
+  N here.
+
+Initial RAM disk (initrd) support
+CONFIG_BLK_DEV_INITRD
+  The initial RAM disk is a RAM disk that is loaded by the boot loader
+  (LOADLIN or LILO) and that is mounted as root before the normal boot
+  procedure. It is typically used to load modules needed to mount the
+  "real" root file system, etc. See Documentation/initrd.txt for
+  details.
+
+Loop device support
+CONFIG_BLK_DEV_LOOP
+  Enabling this option will allow you to mount a file as a file
+  system.  This is useful if you want to check an ISO9660 file system
+  before burning the CD, or want to use floppy images without first
+  writing them to floppy.  This option also allows one to mount a
+  filesystem with encryption.  To use these features, you need a
+  recent version of mount (check the file Documentation/Changes for
+  location and latest version).  Note that this loop device has
+  nothing to do with the loopback device used for network connections
+  from the machine to itself.  Most users will answer N here.
+
+Enhanced IDE/MFM/RLL disk/cdrom/tape support
+CONFIG_BLK_DEV_IDE 
+  This will use the full-featured IDE driver to control up to four IDE
+  interfaces, for a combination of up to eight IDE disk/cdrom/tape
+  drives.  Useful information about large (>540MB) IDE disks,
+  soundcard IDE ports, and other topics, is all contained in
+  Documentation/ide.txt.  If you have one or more IDE drives, say Y
+  here.  If your system has no IDE drives, or if memory requirements
+  are really tight, you could say N here, and select the Old harddisk
+  driver instead to save about 13kB of memory in the kernel.  To
+  fine-tune IDE drive/interface parameters for improved performance,
+  look for the hdparm package at
+  sunsite.unc.edu:/pub/Linux/kernel/patches/diskdrives/
+
+Old harddisk (MFM/RLL/IDE) driver
+CONFIG_BLK_DEV_HD_ONLY
+  There are two drivers for MFM/RLL/IDE disks.  Most people use the
+  newer enhanced driver, but the old one is still around for two
+  reasons.  Some older systems have strange timing problems and seem
+  to work only with the old driver (which itself does not work with
+  some newer systems).  The other reason is that the old driver is
+  smaller, since it lacks the enhanced functionality of the new one.
+  This makes it a good choice for systems with very tight memory
+  restrictions, or for systems with only older MFM/RLL/ESDI drives.
+  Choosing the old driver can save 13kB or so of kernel memory.  If
+  you are unsure, then just choose the Enhanced IDE/MFM/RLL driver
+  instead of this one.
+
+Use old disk-only driver on primary interface
+CONFIG_BLK_DEV_HD_IDE
+  There are two drivers for MFM/RLL/IDE disks.  Most people use just
+  the new enhanced driver by itself.  This option installs the old
+  harddisk driver to control the primary IDE/disk interface in the
+  system, leaving the new enhanced IDE driver take care of only the
+  2nd/3rd/4th IDE interfaces. Doing this will prevent you from having
+  an IDE/ATAPI CDROM or tape drive connected to the primary IDE
+  interface. Choosing this option may be useful for older systems
+  which have MFM/RLL/ESDI controller+drives at the primary port
+  address (0x1f0), along with IDE drives at the secondary/3rd/4th port
+  addresses.  Normally, just say N here; you will then use the new
+  driver for all 4 interfaces.
+  
+Include IDE/ATAPI CDROM support
+CONFIG_BLK_DEV_IDECD
+  If you have a CDROM drive using the ATAPI protocol, say Y.  ATAPI is
+  a new protocol used by IDE CDROM and TAPE drives, similar to the
+  SCSI protocol.  Most new CDROM drives use ATAPI, including the
+  NEC-260, Mitsumi FX400, Sony 55E, and just about all non-SCSI
+  double(2X), quad(4X), and six(6X) speed drives.  At boot time, the
+  TAPE drive will be identified along with other IDE devices, as "hdb"
+  or "hdc", or something similar.
+  If this is your only CDROM drive, you can say N to all other CDROM
+  options, but be sure to say Y to the ISO9660 filesystem.  Read the
+  CDROM-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO and the file
+  Documentation/cdrom/ide-cd.  Note that older versions of lilo (the
+  linux boot loader) cannot properly deal with IDE/ATAPI CDROMs, so
+  install lilo-16 or higher, available from
+  sunsite.unc.edu:/pub/Linux/system/Linux-boot/lilo.
+
+Include IDE/ATAPI TAPE support
+CONFIG_BLK_DEV_IDETAPE
+  If you have an IDE tape drive using the ATAPI protocol, say Y.
+  ATAPI is a new protocol used by IDE TAPE and ATAPI drives,
+  similar to the SCSI protocol.  At boot time, the TAPE drive will
+  be identified along with other IDE devices, as "hdb" or "hdc",
+  or something similar.  Be sure to consult the drivers/block/ide-tape.c
+  and Documentation/ide.txt files for usage information.
+
+Support removable IDE interfaces (PCMCIA)
+CONFIG_BLK_DEV_IDE_PCMCIA
+  This option adds code to the IDE driver to handle hot insertion
+  and removal of IDE interfaces and drives, under direction of an
+  external utility (?).  Normally, just say N here.
+
+CMD640 chipset bugfix/support
+CONFIG_BLK_DEV_CMD640
+  The CMD-Technologies CMD640 chip is used on many common 486 and
+  Pentium motherboards, usually in combination with a "Neptune" or
+  "SiS" chipset.  Unfortunately, it has a number of rather nasty
+  design flaws that can cause severe data corruption under many common
+  conditions.  Say Y here to include code which tries to automatically
+  detect and correct the problems under Linux.  This option also
+  enables access to the secondary IDE ports in some CMD640 based
+  systems.  This driver will work automatically in PCI based systems
+  (most new systems have PCI slots).  But if your system uses VESA
+  local bus (VLB) instead of PCI, you must also supply a kernel boot
+  parameter to enable the CMD640 bugfix/support: "ide0=cmd640_vlb" The
+  CMD640 chip is also used on add-in cards by Acculogic, and on the
+  "CSA-6400E PCI to IDE controller" that some people have. For
+  details, read Documentation/ide.txt. If unsure, say Y.
+
+CMD640 enhanced support
+CONFIG_BLK_DEV_CMD640_ENHANCED
+  This option includes support for setting/autotuning PIO modes and
+  prefetch on CMD640 IDE interfaces.  For details, read
+  Documentation/ide.txt. If you have a CMD640 IDE interface and your
+  BIOS does not already do this for you, then say Y here.  Otherwise
+  say N.
+
+RZ1000 chipset bugfix/support
+CONFIG_BLK_DEV_RZ1000
+  The PC-Technologies RZ1000 chip is used on many common 486 and
+  Pentium motherboards, usually along with the "Neptune" chipset.
+  Unfortunately, it has a rather nasty design flaw that can cause
+  severe data corruption under many conditions.  Say Y here to include
+  code which automatically detects and corrects the problem under
+  Linux.  This may slow disk throughput by a few percent, but at least
+  things will operate 100% reliably. If unsure, say Y.
+
+Other IDE chipset support
+CONFIG_IDE_CHIPSETS
+  Say Y here if you want to include enhanced support for various IDE
+  interface chipsets used on motherboards and add-on cards.  This
+  enhanced support may be necessary for linux to be able to access the
+  3rd/4th drives in some systems.  It may also enable setting of
+  higher speed I/O rates to improve system performance with these
+  chipsets.  Most of these also require special kernel boot parameters
+  to actually turn on the support at runtime.
+
+DTC-2278 support
+CONFIG_BLK_DEV_DTC2278
+  This driver is enabled at runtime using the "ide0=dtc2278" kernel
+  boot parameter.  It enables support for the secondary IDE interface
+  of the DTC-2278 card, and permits faster I/O speeds to be set as
+  well.  See the Documentation/ide.txt and dtc2278.c files for more
+  info.
+
+Holtek HT6560B support
+CONFIG_BLK_DEV_HT6560B
+  This driver is enabled at runtime using the "ide0=ht6560b" kernel
+  boot parameter.  It enables support for the secondary IDE interface
+  of the Holtek card, and permits faster I/O speeds to be set as well.
+  See the Documentation/ide.txt and ht6560b.c files for more info.
+
+QDI QD6580 support
+CONFIG_BLK_DEV_QD6580
+  This driver is enabled at runtime using the "ide0=qd6580" kernel
+  boot parameter.  It permits faster I/O speeds to be set.  See the
+  Documentation/ide.txt and qd6580.c files for more info.
+
+UMC 8672 support
+CONFIG_BLK_DEV_UMC8672
+  This driver is enabled at runtime using the "ide0=umc8672" kernel
+  boot parameter.  It enables support for the secondary IDE interface
+  of the UMC-8672, and permits faster I/O speeds to be set as well.
+  See the Documentation/ide.txt and umc8672.c files for more info.
+
+ALI M14xx support
+CONFIG_BLK_DEV_ALI14XX
+  This driver is enabled at runtime using the "ide0=ali14xx" kernel
+  boot parameter.  It enables support for the secondary IDE interface
+  of the ALI M1439/1443/1445/1487/1489 chipsets, and permits faster
+  I/O speeds to be set as well.  See the Documentation/ide.txt and
+  ali14xx.c files for more info.
+
+PROMISE DC4030 support (EXPERIMENTAL)
+CONFIG_BLK_DEV_PROMISE
+  This driver is enabled at runtime using the "ide0=dc4030" kernel
+  boot parameter.  It enables support for the secondary IDE interface
+  of the chipset, and takes advantage of the caching features of the
+  card.  This driver is known to incur timeouts/retries during heavy
+  I/O to drives attached to the secondary interface.  CDROM and TAPE
+  devices are not supported yet.  See the Documentation/ide.txt and
+  promise.c files for more info.
+
+XT harddisk support
+CONFIG_BLK_DEV_XD
+  Very old 8 bit hard disk controllers used in the IBM XT computer. To
+  include a driver for these, say Y. If you want to compile the 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. It's pretty unlikely that you have one of
+  these: say N.
+
+Multiple devices driver support
+CONFIG_BLK_DEV_MD
+  This driver lets you combine several harddisk partitions into one
+  logical block device. Information about how and why to use it and the
+  necessary tools are available over ftp (user: anonymous) from
+  sweet-smoke.ufr-info-p7.ibp.fr/pub/public/Linux in the md package
+  and the md-FAQ. Please read drivers/block/README.md. If unsure, say
+  N.
+
+Linear (append) mode
+CONFIG_MD_LINEAR
+  If you enable this, then your multiple devices driver will be able
+  to use the so-called linear mode, i.e. it will combine the harddisk
+  partitions by simply appending one to the other. If you want to
+  compile this 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. If unsure, say Y.
+
+RAID-0 (striping) mode
+CONFIG_MD_STRIPED
+  If you enable this, then your multiple devices driver will be able
+  to use the so-called raid0 mode, i.e. it will combine the harddisk
+  partitions into one logical device in such a fashion as to fill them
+  up evenly, one chunk here and one chunk there. This will increase
+  the throughput rate if the partitions reside on distinct disks.  If
+  you want to compile this 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. If unsure, say Y.
+
+Support for Deskstation RPC44 
+CONFIG_DESKSTATION_RPC44
+  This is a machine with a R4400 100 MHz CPU. To compile a Linux
+  kernel that runs on these, say Y here. For details about Linux
+  on the MIPS architecture, check out the Linux/MIPS FAQ on the WWW at
+  http://lena.fnet.fr/ (To browse the WWW, you need to
+  have access to a machine on the Internet that has one of the
+  programs lynx, netscape or Mosaic).
+
+Support for Mips Magnum 3000 
+CONFIG_MIPS_MAGNUM_3000
+  To compile a Linux kernel that runs on these, say Y here. For
+  details about Linux on the MIPS architecture, check out the
+  Linux/MIPS FAQ on the WWW at http://lena.fnet.fr/ (To browse the
+  WWW, you need to have access to a machine on the Internet that has
+  one of the programs lynx, netscape or Mosaic).
+
+Support for Mips Magnum 4000
+CONFIG_MIPS_MAGNUM_4000
+  This is a machine with a R4000 100 MHz CPU. To compile a Linux
+  kernel that runs on these, say Y here. For details about Linux
+  on the MIPS architecture, check out the Linux/MIPS FAQ on the WWW at
+  http://lena.fnet.fr/ (To browse the WWW, you need to
+  have access to a machine on the Internet that has one of the
+  programs lynx, netscape or Mosaic).
+
+Support for Olivetti M700
+CONFIG_OLIVETTI_M700
+  This is a machine with a R4000 100 MHz CPU. To compile a Linux
+  kernel that runs on these, say Y here. For details about Linux
+  on the MIPS architecture, check out the Linux/MIPS FAQ on the WWW at
+  http://lena.fnet.fr/ (To browse the WWW, you need to
+  have access to a machine on the Internet that has one of the
+  programs lynx, netscape or Mosaic).
+
+Support for Deskstation Tyne
+CONFIG_DESKSTATION_TYNE
+  This is a machine with a R4600 134 MHz CPU. The Linux port for this
+  system is idle right now because of hardware or documentation
+  problems. For details about Linux on the MIPS architecture, check
+  out the Linux/MIPS FAQ on the WWW at http://lena.fnet.fr/ (To browse
+  the WWW, you need to have access to a machine on the Internet that
+  has one of the programs lynx, netscape or Mosaic).
+
+Support for Acer PICA 1 chipset
+CONFIG_ACER_PICA_61
+  This is a machine with a R4400 134/150 MHz CPU. To compile a Linux
+  kernel that runs on these, say Y here. For details about
+  Linux on the MIPS architecture, check out the Linux/MIPS FAQ on the
+  WWW at http://lena.fnet.fr/ (To browse the WWW, you need to have
+  access to a machine on the Internet that has one of the programs
+  lynx, netscape or Mosaic).
+
+Support for DECstation
+CONFIG_MIPS_DECSTATION
+  The DECStation 3100 (with a MIPS R2000 series CPU) and DECStation
+  5000/xxx (MIPS R3000 series CPU) are also sometimes labeled
+  PMAX. They often run the Ultrix operating system. To compile a Linux
+  kernel that runs on these, say Y here. For details about Linux
+  on the MIPS architecture, check out the Linux/MIPS FAQ on the WWW at
+  http://lena.fnet.fr/ (To browse the WWW, you need to
+  have access to a machine on the Internet that has one of the
+  programs lynx, netscape or Mosaic).
+
+CPU type
+CONFIG_CPU_R3000
+  Give the type of your machine's MIPS CPU. For this question,
+  it suffices to give a unique prefix of the option you want to
+  choose. 
+
+Networking support
+CONFIG_NET
+  Unless you really know what you are doing, you should say Y
+  here. The reason is that some programs need it even if you configure
+  a stand-alone machine that won't be connected to any other computer.
+  from an older kernel, you should consider updating your networking
+  tools too; read net/README for details.
+
+Network aliasing
+CONFIG_NET_ALIAS
+  This is for setting multiple IP addresses on the same low-level
+  network device driver. Typically used for services that act
+  differently based on the address they listen on (e.g. "multihosting"
+  on Apache httpd) or for connecting to different logical networks
+  through the same physical interface.  This is the generic part,
+  later when configuring network protocol options you will be asked
+  for protocol-specific aliasing support.  See
+  Documentation/networking/alias.txt for more info.  If you need this
+  feature (for any protocol, like IP) say Y; if unsure, say N.
+
+Network firewalls
+CONFIG_FIREWALL
+  A firewall is a computer which protects a local network from the
+  rest of the World: all traffic to and from computers on the local
+  net is inspected by the firewall first. If you want to configure
+  your Linux box as a firewall for a local network, say Y here. If
+  your local network is TCP/IP based, you will have to say Y to "IP:
+  firewalling", below.  You also need to say Y here and enable "IP
+  firewalling" below in order to be able to use IP masquerading
+  (i.e. local computers can chat with an outside host, but that
+  outside host is made to think that it is talking to the firewall
+  box. Makes the local network completely invisible and avoids the
+  need to allocate valid IP host addresses for the machines on the
+  local net) or to use the ip packet accounting to see what is using
+  all your network bandwidth. Chances are that you should use this on
+  any machine being run as a router and not on a host. If unsure, say
+  N.
+
+Sun floppy controller support
+CONFIG_BLK_DEV_SUNFD
+  This is support for floppy drives on Sun Sparc workstations. Say Y
+  if you have a floppy drive, otherwise N. Easy.
+
+Alpha system type
+CONFIG_ALPHA_AVANTI
+  Find out what type of Alpha motherboard you have. You will probably
+  want to read the Linux/Alpha homepage on the WWW at
+  http://www.azstarnet.com/~axplinux/ (To browse the WWW, you need to
+  have access to a machine on the Internet that has one of the
+  programs lynx, netscape or Mosaic). For this question, it suffices
+  to give a unique prefix of the option you want to choose. The
+  choices:
+  ** Avanti: This is for Mustang (AS200), M3 (AS250), Avanti (AS400)
+     and XL (a.k.a. "Windows NT Dream Machine" :-) AlphaStations.
+     These usually come with a TGA graphics adaptor, so you'll want to
+     say Y to "TGA Console support", below, if you have one of these.
+  ** Jensen: a.k.a. DEC 2000 a.k.a. DECpc AXP 150, the oldest Alpha
+     PC; it sports an EISA bus. The boot process on Jensen machines is
+     difficult (no booting from floppies, MILO doesn't work). You need
+     to have access to a second Linux workstation. The Linux/Alpha
+     FAQ, accessible from the above mentioned WWW page, has details.
+  ** Noname: a.k.a. AXPpci33, a PCI-bus based board using the 21066
+     Alpha CPU, running at either 166 or 233 MHz. You also want to
+     choose this option if you have a UDB (Universal Desktop Box
+     a.k.a. Multia) machine.
+  ** Cabriolet: also called AlphaPC64, a PCI-bus based board using the
+     21064 Alpha CPU typically running at 275 or 300 MHz.
+  ** EB66: "Evaluation Board"
+  ** EB66+: "Evaluation Board"
+###
+### Add info about Platform2000, EB164
+###
+
+Is it really a true XL
+CONFIG_ALPHA_XL
+  If your Avanti Machine is of type XL (a.k.a. "Windows NT Dream
+  Machine") (as opposed to Mustang (AS200), M3 (AS250) or Avanti
+  (AS400)), say Y, otherwise N.
+
+Limit memory to low 16MB
+CONFIG_MAX_16M
+  This is for some buggy motherboards which cannot properly deal with
+  the memory above 16MB. If you have more than 16MB of RAM and
+  experience weird problems, you might want to try Y, everyone else
+  says N. Note for machines with more that 64MB of RAM: in order for
+  the kernel to be able to use the memory above 64MB, pass the command
+  line option "mem=XXXM" (where XXX is the memory size in megabytes)
+  to your kernel during boot time. See the documentation of your boot
+  loader (lilo or loadlin) about how to pass options to the
+  kernel. The lilo procedure is also explained in the SCSI-HOWTO,
+  available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  You also need at least 512kB
+  of RAM cache if you have more than 64MB of RAM.  Some other things
+  to try when experiencing seemingly random, "weird" problems: 1)
+  passing the "no-hlt" option to the kernel 2) passing the "no-387"
+  option to the kernel 3) passing the "mem=4M" option to the kernel
+  (thereby disabling all but the first 4M of RAM) 4) disabling the
+  cache from your BIOS settings 5) exchanging RAM chips 6) exchanging
+  the motherboard.
+
+Using SRM as bootloader
+CONFIG_ALPHA_SRM
+  There are two different types of booting firmware on Alphas: SRM,
+  which is command line driven, and ARC, which uses menus and arrow
+  keys. The usual way to load Linux on an Alpha machine is to use MILO
+  (a bootloader that lets you pass command line parameters to the
+  kernel just like LILO does) which can be loaded either from ARC or
+  can be installed directly as a permanent firmware replacement from
+  floppy (which requires changing a certain jumper on the
+  motherboard). If you want to do either of these, say N here. If MILO
+  doesn't work on your system (true for Jensen motherboards), you can
+  bypass it altogether and boot Linux directly from an SRM console;
+  say Y here in order to do that. Note that you won't be able to boot
+  from an IDE disk using SRM. If unsure, say N. Details about the
+  Linux/Alpha booting process are contained in the Linux/Alpha FAQ,
+  accessible on the WWW from http://www.azstarnet.com/~axplinux/ (To
+  browse the WWW, you need to have access to a machine on the Internet
+  that has one of the programs lynx, netscape or Mosaic).
+
+Echo console messages on /dev/ttyS1
+CONFIG_SERIAL_ECHO
+  If you enable this option, all kernel messages that would usually go
+  to the console will also be sent to the device /dev/ttyS1 which
+  corresponds to a serial port; this could be useful if you attached
+  a terminal or printer to that port.
+
+TGA Console Support
+CONFIG_TGA_CONSOLE
+  Many Alpha systems (e.g the Multia) are shipped with a graphics card
+  that implements the TGA interface (much like the VGA standard, but
+  older TGA adaptors are *not* VGA compatible).  On such systems, this
+  option needs to be enabled so that the TGA driver rather than the
+  standard VGA driver is used.  Note that, at this time, there is no X
+  server for these systems. If unsure, try N.
+
+PCI bios support
+CONFIG_PCI
+  Find out whether you have a PCI motherboard. PCI is the name of a
+  bus system, i.e. the way the CPU talks to the other stuff inside
+  your box. Other bus systems are ISA, EISA, Microchannel (MCA) or
+  VESA. If you have PCI, say Y, otherwise N. Note1: MCA systems
+  (notably some IBM PS/2's) are not supported by the standard kernels,
+  but patches exist at
+  http://www.undergrad.math.uwaterloo.ca/~cpbeaure/mca-linux.html on
+  the WWW. Note2: some old PCI motherboards have BIOS bugs and may
+  crash if "PCI bios support" is enabled (but they run fine without
+  this option). The PCI-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO, contains valuable information
+  about which PCI hardware does work under Linux and which doesn't.
+  If some of your PCI devices don't work and you get a warning during
+  boot time ("man dmesg"), please follow the instructions at the top
+  of include/linux/pci.h. 
+
+PCI bridge optimization (experimental)
+CONFIG_PCI_OPTIMIZE
+  This can improve access times for some hardware devices under
+  certain BIOSes if your computer uses a PCI bus system. This is
+  recommended; say Y.
+
+Intel 82371 PIIX (Triton I/II) DMA support
+CONFIG_BLK_DEV_TRITON
+  If your PCI system uses an IDE harddrive (as opposed to SCSI, say)
+  and includes the Intel 430FX PCI Triton chipset, you will want to
+  enable this option to allow use of bus-mastering DMA data transfers.
+  Read the comments at the beginning of drivers/block/triton.c.  Check
+  the file Documentation/Changes for location and latest version of
+  the hdparm utility. It is safe to say Y to this question.
+
+System V IPC
+CONFIG_SYSVIPC
+  Inter Process Communication is a suite of library functions and system
+  calls which let processes (= running programs) synchronize and
+  exchange information. It is generally considered to be a good thing,
+  and some programs won't run unless you enable this. In particular,
+  if you want to run the DOS emulator dosemu under Linux (read the
+  DOSEMU-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO), you'll need to say Y here. You
+  can find documentation about IPC in ipc.info, which is contained in
+  sunsite.unc.edu:/pub/Linux/docs/man/info.tar.gz (extract with "tar
+  xzvf filename"). These docs are in the info format which is used to
+  document GNU software and can be read from within emacs ("Ctrl-h i")
+  or with the program info ("man info"). Enabling this option enlarges
+  your kernel by about 7kB. Just say Y.
+
+Kernel support for ELF binaries
+CONFIG_BINFMT_ELF
+  ELF (Executable and Linkable Format) is a format for libraries and
+  executables used across different architectures and operating
+  systems. This option will enable your kernel to run ELF binaries and
+  enlarge it by about 2kB. ELF support under Linux is quickly
+  replacing the traditional Linux a.out formats (QMAGIC and ZMAGIC)
+  because it is portable (this does *not* mean that you will be able
+  to run executables from different architectures or operating
+  systems!) and makes building run-time libraries very easy. Many new
+  executables are distributed solely in ELF format. You definitely
+  want to say Y here. Information about ELF is on the WWW at
+  http://www.sjc.ox.ac.uk/users/barlow/elf-howto.html (To browse the
+  WWW, you need to have access to a machine on the Internet that has
+  one of the programs lynx, netscape or Mosaic).  If you find that
+  after upgrading to Linux kernel 1.3 and saying Y here, you still
+  can't run any ELF binaries (they just crash), then you'll have to
+  install the newest ELF runtime libraries, including ld.so (check the
+  file Documentation/Changes for location and latest version). If you
+  want to compile this 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. Saying M or N here is dangerous
+  because some crucial programs on your system might be in ELF format.
+
+Compile kernel as ELF - if your GCC is ELF-GCC
+CONFIG_KERNEL_ELF
+  The gcc version 2.7.0 and newer produces the new ELF binary format
+  as default. If you have such a compiler (try "gcc -v"), say Y here,
+  otherwise N.  
+  It is possible, albeit almost pointless, to compile the kernel in
+  a.out (i.e. QMAGIC) format even if your compiler produces ELF as
+  default. For that, you would have to say N here and change the
+  variables LD and CC in the toplevel Makefile. Similarly, if your
+  compiler produces a.out by default but is able to produce ELF, you
+  can compile the kernel in ELF by saying Y here and editing the
+  variables CC and LD in the toplevel Makefile.
+
+Kernel support for A.OUT binaries
+CONFIG_BINFMT_AOUT
+  A.out (Assembler.OUTput) is a set of formats for libraries and
+  executables used in the earliest versions of UNIX. Linux used the
+  a.out formats QMAGIC and ZMAGIC until they were replaced with the
+  ELF format.
+  As more and more programs are converted to ELF, the use for a.out
+  will gradually diminish. If you disable this option it will reduce
+  your kernel by one page. This is not much and by itself does not
+  warrant removing support. However its removal is a good idea if you
+  wish to ensure that absolutely none of your programs will use this
+  older executable format. If you don't know what to answer at this
+  point then answer Y. If someone told you "You need a kernel with
+  QMAGIC support" then you'll have to say Y here. You may answer M 
+  to compile a.out support as a module and later load the module when
+  you want to use a program or library in a.out format. Saying M or N
+  here is dangerous though, because some crucial programs on your
+  system might still be in A.OUT format.
+
+Kernel support for JAVA binaries
+CONFIG_BINFMT_JAVA
+  JAVA is an object oriented programming language developed by SUN;
+  JAVA programs are compiled into "JAVA bytecode" which can then be
+  interpreted by run time systems on many different operating systems.
+  These JAVA binaries are becoming a universal executable format. This
+  option allows you to run a Java binary just like any other Linux
+  program: by typing in its name. As more and more Java programs
+  become available, the use for this will gradually increase. You can
+  even execute HTML files containing JAVA applets (= JAVA binaries) if
+  those files start with the string "<!--applet-->". If you want to
+  use this, read Documentation/java.txt and the Java on Linux HOWTO,
+  available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. You will then need to install
+  the run time system contained in the Java Developers Kit (JDK) as
+  described in the HOWTO. If you disable this option it will reduce
+  your kernel by about 4kB. This is not much and by itself does not
+  warrant removing support. However its removal is a good idea if you
+  do not have the JDK installed. If you don't know what to answer at
+  this point then answer Y. You may answer M for module support and
+  later load the module when you install the JDK or find an interesting
+  Java program that you can't live without.
+
+Processor type
+CONFIG_M386
+  This is the processor type of your CPU. It is used for optimizing
+  purposes. In order to compile a kernel that can run on all CPU types
+  (albeit not optimally fast), you can specify "386" here.  If you
+  specify "486" or "Pentium" or "PPro", then the kernel will run on
+  486 and Pentium (=586) and Pentium Pro (=686) CPUs. In rare cases,
+  it can make sense to specify "Pentium" even if running a 486: the
+  kernel will be smaller but slower. On the other hand, if you use a
+  compiler before gcc 2.7 (say "gcc -v" to find out), then you have to
+  say "386" or "486" here even if running on a Pentium or PPro
+  machine. If you don't know what to do, say "386".
+
+Compile the kernel into the ELF object format 
+CONFIG_ELF_KERNEL
+  ELF (Executable and Linkable Format) is a format for libraries and
+  executables used across different architectures and operating
+  systems. This option will cause the resulting kernel to be in ELF
+  format, which is generally desirable, so say Y. However, it only
+  works if your compiler and linker can produce ELF code.
+
+Is your ELF compiler an extra compiler
+CONFIG_EXTRA_ELF_COMPILER
+  If you have a linuxelf-gcc as opposed to linux-gcc, say Y, otherwise
+  N.
+
+Generate little endian code
+CONFIG_CPU_LITTLE_ENDIAN
+  If your compiler is mipsel-linux-gcc or mipsel-linuxelf-gcc (as
+  opposed to mips-linux-gcc or mips-linuxelf-gcc), say Y here,
+  otherwise N. Most MIPS machines use little-endian code, but it might
+  be necessary to run older Mips systems, such as the Sony News and
+  MIPS RC3xxx, in big endian mode.
+
+Enable loadable module support
+CONFIG_MODULES
+  Kernel modules are small pieces of compiled code which can be 
+  inserted in or removed from the running kernel, using the
+  programs insmod and rmmod. This is described in the file 
+  Documentation/modules.txt. Modules can be device drivers, file 
+  systems, binary executable formats, and so on. If you think that 
+  you may want to make use of modules with this kernel in the future, 
+  then say Y here. If unsure, say Y.
+
+Set version information on all symbols for modules
+CONFIG_MODVERSIONS
+  Usually, modules have to be recompiled whenever you switch to a new
+  kernel. Enabling this option makes it possible, and safe, to use the
+  same modules even after compiling a new kernel; this requires the
+  program modprobe. All the software needed for module support is in
+  the modules package (check the file Documentation/Changes for
+  location and latest version).  NOTE: if you say Y here but don't
+  have the program genksyms (which is also contained in the above
+  mentioned modules package), then the building of your kernel will
+  fail.  If you are going to use modules that are generated from
+  non-kernel sources, you would benefit from this option. Otherwise
+  it's not that important. So, N ought to be a safe bet.
+
+Kernel daemon support
+CONFIG_KERNELD
+  Normally when you have selected some drivers and/or filesystems to
+  be created as loadable modules, you also have the responsibility to
+  load the corresponding module (via insmod/modprobe) before you can
+  use it.  If you select Y here, the kernel will take care of this all
+  by itself, together with the user level daemon "kerneld".  Note that
+  "kerneld" will also automatically unload all unused modules, so you
+  don't have to use "rmmod" either.
+  kerneld will also provide support for different user-level beeper
+  and screen blanker programs later on.
+  The "kerneld" daemon is included in the package "modules-1.2.8" and
+  later. You will probably want to read the kerneld mini-HOWTO,
+  available via ftp (user: anonymous) from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini. If unsure, say Y.
+
+ARP daemon support (EXPERIMENTAL)
+CONFIG_ARPD
+  Normally, the kernel maintains an internal cache which maps IP 
+  addresses to hardware addresses on the local network, so that
+  Ethernet/Token Ring/ etc. frames are sent to the proper address on
+  the physical networking layer.  For small networks having a few
+  hundred directly connected hosts or less, keeping this address
+  resolution (ARP) cache inside the kernel works well.  However,
+  maintaining an internal ARP cache does not work well for very large
+  switched networks, and will use a lot of kernel memory if TCP/IP
+  connections are made to many machines on the network.  By enabling
+  this option, the kernel's internal ARP cache will never grow to more
+  than 256 entries (the oldest entries are expired in a LIFO manner)
+  and communication will be attempted with an external ARP daemon,
+  arpd.  This code is still experimental.  If you do enable arpd
+  support, you should obtain a copy of arpd from
+  http://www.loran.com/~layes/arpd/index.html.  If unsure, say N.
+
+TCP/IP networking
+CONFIG_INET
+  These are the protocols used on the Internet and on most local
+  Ethernets. The safest is to say Y here (which will enlarge your
+  kernel by about 35 kB), since some programs (e.g. the X window
+  system) use TCP/IP even if your machine is not connected to any
+  other computer. You will get the so-called loopback device which
+  allows you to ping yourself (great fun, that!). This option is also
+  necessary if you want to use the full power of term (term is a
+  program which gives you almost full Internet connectivity if you
+  have a regular dial up shell account on some Internet connected Unix
+  computer. Read the Term-HOWTO, available via ftp (user: anonymous)
+  on sunsite.unc.edu:/pub/Linux/docs/HOWTO).  Short answer:
+  say Y.
+
+IP: forwarding/gatewaying
+CONFIG_IP_FORWARD
+  People who want to use their Linux box as the router for a local
+  network (i.e. the computer responsible for distributing Internet
+  traffic to and from the machines in the local network and the
+  subnetworks) should say Y here (thereby enlarging their kernel by
+  about 5 kB). Note that in this case, you possibly have two ethernet
+  devices in your computer: one for the "outside world" and one for
+  your local net. The kernel is not able to recognize both at boot
+  time without help; for details read the
+  Multiple-Ethernet-mini-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.  If your box is
+  connected to two networks, it may still make sense to say N here,
+  namely if you want to turn your box into a firewall protecting a
+  local network from the internet. The Firewall-HOWTO tells you how to
+  do this. If your setup is more complex, say you are connected to
+  three networks and you want to act as a firewall between two of them
+  and route traffic for the others, you need to say Y here and enable
+  IP firewalling below. If you intend to use IP masquerading (i.e. IP
+  traffic from one of the local computers and destined for an outside
+  host is changed by your box so that it appears to come from you),
+  you'll have to say Y here and also to IP firewalling and IP
+  masquerading below. You should also say Y here if you want to
+  configure your box as a SLIP (the protocol for sending internet
+  traffic over telephone lines) or PPP (a better SLIP) server for
+  other people to dial into and your box is connected to a local
+  network at the same time. You would then most likely use proxy-ARP
+  (Address Resolution Protocol), explained in the Proxy-Arp mini howto
+  on sunsite in /pub/Linux/docs/HOWTO/mini. You also need to say Y
+  here if you want to run mrouted in order to do multicast routing as
+  used on the MBONE (a high bandwidth network on top of the internet
+  which carries audio and video broadcasts) for example. In this case,
+  say Y to "IP: multicasting" and "IP: multicast routing" as well. If
+  unsure, say N.
+
+IP: multicasting
+CONFIG_IP_MULTICAST
+  This is code for addressing several networked computers at once,
+  enlarging your kernel by about 2 kB. If you are using gated, the
+  daemon that updates your computer's routing tables, you will need to
+  have this option compiled in. You also need multicasting if you
+  intend to participate in the MBONE, a high bandwidth network on top
+  of the internet which carries audio and video broadcasts. More
+  information about the MBONE is on the WWW at
+  http://www.best.com/~prince/techinfo/mbone.html (to browse the WWW,
+  you need to have access to a machine on the Internet that has one of
+  the programs lynx, netscape or Mosaic). Information about the
+  multicast capabilities of the various network cards is contained in
+  drivers/net/README.multicast. For most people, it's safe to say N.
+
+IP: optimize as router not host
+CONFIG_IP_ROUTER
+  Some Linux network drivers use a technique called copy and checksum
+  to optimize host performance. For a machine which is forwarding most
+  packets to another host this is however a loss. This parameter turns
+  off copy and checksum from devices. It may make other changes in the
+  future.
+
+IP: firewalling
+CONFIG_IP_FIREWALL
+  If you want to configure your Linux box as a firewall for a local
+  TCP/IP based network, say Y here. This will enlarge your kernel by
+  about 2kB. You may need to read the FIREWALL-HOWTO, available via
+  ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. Also, you will need the
+  ipfwadm tool (check the file Documentation/Changes for location and
+  latest version) to allow selective blocking of internet traffic
+  based on type, origin and destination.  You need to enable IP
+  firewalling in order to be able to use IP masquerading (i.e. local
+  computers can chat with an outside host, but that outside host is
+  made to think that it is talking to the firewall box. Makes the
+  local network completely invisible and avoids the need to allocate
+  valid IP host addresses for the machines on the local net) or to use
+  the IP packet accounting to see what is using all your network
+  bandwidth.  This option is also needed when you want to enable the
+  transparent proxying support (makes the computers on the local
+  network think they're talking to a remote computer, while in reality
+  the traffic is redirected by your Linux firewall to a local proxy
+  server).
+
+IP: firewall packet netlink device
+CONFIG_IP_FIREWALL_NETLINK
+  When packets hit the firewall and are blocked the first 128 bytes of each
+  datagram is passed to optional user space monitoring software that can
+  then look for attacks and take actions such as paging the administrator of
+  the site.
+
+IP: accounting
+CONFIG_IP_ACCT
+  This keeps track of your IP network traffic and produces some
+  statistics. Usually, you only want to say Y here if your box will be
+  a router or a firewall for some local network, in which case you
+  naturally should have said Y to IP forwarding/gatewaying resp. IP
+  firewalling. The data is accessible with "cat /proc/net/ip_acct", so
+  you want to say Y to the /proc filesystem below, if you say Y
+  here. To specify what exactly should be recorded, you need the tool
+  ipfwadm (check the file Documentation/Changes for location and
+  latest version).
+
+IP: tunneling
+CONFIG_NET_IPIP
+  Tunneling means encapsulating data of one protocol type within
+  another protocol and sending it over a channel that understands the
+  encapsulating protocol. This particular tunneling driver implements
+  encapsulation of IP within IP, which sounds kind of pointless, but
+  can be useful if you want to make your (or some other) machine
+  appear on a different network than it physically is, or to use
+  mobile-IP facilities (allowing laptops to seamlessly move between
+  networks without changing their IP addresses; check out
+  http://anchor.cs.binghamton.edu/~mobileip/LJ/index.html). Enabling
+  this option will produce two modules ( = code which can be inserted
+  in and removed from the running kernel whenever you want), one
+  encapsulator and one decapsulator. You can read details in
+  drivers/net/README.tunnel. Most people can say N.
+  
+IP: firewall packet logging
+CONFIG_IP_FIREWALL_VERBOSE
+  This gives you information about what your firewall did with
+  packets it received. The information is handled by the klogd demon
+  which is responsible for kernel messages ("man klogd").
+
+IP: transparent proxying (EXPERIMENTAL)
+CONFIG_IP_TRANSPARENT_PROXY
+  This enables your Linux firewall to transparently redirect any
+  network traffic originating from the local network and destined
+  for a remote host to a local server, called a "transparent proxy
+  server".  This makes the local computers think they are talking to
+  the remote end, while in fact they are connected to the local
+  proxy. Redirection is activated by defining special input firewall
+  rules (using the ipfwadm utility) and/or by doing an appropriate
+  bind() system call.
+
+IP: masquerading (EXPERIMENTAL)
+CONFIG_IP_MASQUERADE
+  If one of the computers on your local network for which your Linux
+  box acts as a firewall wants to send something to the outside, your
+  box can "masquerade" as that host, i.e. it forwards the traffic to
+  the intended destination, but makes it look like it came from the
+  firewall box itself. It works both ways: if the outside host
+  answers, the firewall will silently forward the traffic to the
+  corresponding local computer. This way, the computers on your local
+  net are completely invisible to the outside world, even though they
+  can reach the outside and can be reached. This makes it possible to
+  have the computers on the local network participate on the internet
+  even if they don't have officially registered IP addresses.  (This
+  last problem can also be solved by connecting the Linux box to the
+  Internet using SLiRP [SLiRP is a SLIP/PPP emulator that works if you
+  have a regular dial up shell account on some UNIX computer; get it
+  from ftp://sunsite.unc.edu/pub/Linux/system/Network/serial/].)
+  Details on how to set things up are contained in the
+  IP Masquerading FAQ, available at http://www.indyramp.com/masq/
+  This is EXPERIMENTAL code, which means that it need not be completely
+  stable. If you want this, say Y.
+
+IP: always defragment 
+CONFIG_IP_ALWAYS_DEFRAG 
+  This option means that all incoming fragments (= parts of IP packets
+  that arose when some host between origin and destination decided
+  that the IP packets were too large and cut them in pieces) will be
+  reassembled (defragmented) before being processed, even if they are
+  about to be forwarded.  This option is highly recommended if you
+  have enabled the masquerading support (CONFIG_IP_MASQUERADE),
+  because this facility requires that second and further fragments can
+  be related to TCP or UDP port numbers, which are only stored in the
+  first fragment.  When using IP firewall support
+  (CONFIG_IP_FIREWALL), you might also want to enable this option, to
+  have a more reliable firewall (otherwise second and further
+  fragments will always be accepted by the firewall).  When using
+  transparent proxying (CONFIG_IP_TRANSPARENT_PROXY), this option is
+  implicit, although it is safe to say Y here. Do not say Y to this
+  option except when running either a firewall that is the sole link
+  to your network or a transparent proxy. Never ever say Y to this for
+  a normal router or host.
+
+IP: aliasing support
+CONFIG_IP_ALIAS
+  Sometimes it is useful to give several addresses to a single network
+  interface (= serial port or ethernet card). The most common case is
+  that you want to serve different WWW documents to the outside
+  according to which of your host names they used to connect to
+  you. This is explained in detail on the WWW at
+  http://www.thesphere.com/~dlp/TwoServers/ (to browse the WWW, you
+  need to have access to a machine on the Internet that has one of the
+  programs lynx, netscape or Mosaic). Another scenario would be that
+  there are two logical networks living on your local ethernet and you
+  want to access them both with the same ethernet card. The
+  configuration of these alias addresses is done with a special name
+  syntax explained in Documentation/networking/alias.txt. If you want
+  this, say Y. Most people don't need it and say N.
+
+IP: multicast routing (EXPERIMENTAL)
+CONFIG_IP_MROUTE
+  This is used if you want your machine to act as a router for IP
+  packets that have several destination addresses. It is needed on the
+  MBONE, a high bandwidth network on top of the internet which carries
+  audio and video broadcasts. In order to do that, you would most
+  likely run the program mrouted. Information about the multicast
+  capabilities of the various network cards is contained in
+  drivers/net/README.multicast. If you haven't heard about it, you
+  don't need it.
+
+PC/TCP compatibility mode
+CONFIG_INET_PCTCP
+  If you have been having difficulties telneting to your Linux machine
+  from a DOS system that uses (broken) PC/TCP networking software (all
+  versions up to OnNet 2.0) over your local ethernet  try enabling this
+  option.  Everyone else says N. People having problems with NCSA telnet
+  should see the file linux/Documentation/networking/ncsa-telnet.
+
+Reverse ARP
+CONFIG_INET_RARP
+  Since you asked: if there are (usually diskless or portable)
+  machines on your local network that know their hardware ethernet
+  addresses but don't know their IP addresses upon startup, they can
+  send out a Reverse Address Resolution Protocol (RARP) request to
+  find out their own IP addresses. Diskless Sun 3 machines use this
+  procedure at boot time. If you want your Linux box to be able to
+  *answer* such requests, say Y here; you'd have to run the program
+  rarp ("man rarp") on your box. If you actually want to use a
+  diskless Sun 3 machine as an Xterminal to Linux, say Y here and
+  fetch Linux-Xkernel from
+  ftp://sunsite.unc.edu/pub/Linux/system/Network/boot.net/.  Superior
+  solutions to the problem of booting and configuring machines over a
+  net connection are given by the protocol BOOTP and its successor
+  DHCP. See the DHCP FAQ
+  http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html for details.  If
+  you want to compile RARP support 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.  If you don't
+  understand a word of the above, say N and rest in peace.
+
+Assume subnets are local
+CONFIG_INET_SNARL
+  Say Y if you are on a subnetted network with all machines connected
+  by Ethernet segments only, as this option optimizes network access
+  for this special case. If there are other connections, e.g. SLIP
+  links, between machines of your IP network, say N.  If in doubt, say
+  N. The PATH mtu discovery facility will cover most cases anyway.
+
+Disable Path MTU Discovery (normally enabled)
+CONFIG_NO_PATH_MTU_DISCOVERY
+  MTU (maximal transfer unit) is the size of the chunks we send out
+  over the net. "Path MTU Discovery" means that, instead of always
+  sending very small chunks, we start out sending big ones and if we
+  then discover that some host along the way likes its chunks smaller,
+  we adjust to a smaller size. This is good, so most people say
+  N. However, some versions of DOS NCSA telnet (and other software)
+  are broken and can only connect to your Linux machine if you say Y
+  here. See also Documentation/networking/ncsa-telnet for the location
+  of fixed NCSA telnet clients.
+
+Disable NAGLE algorithm (normally enabled)
+CONFIG_TCP_NAGLE_OFF
+  The NAGLE algorithm works by requiring an acknowledgment before
+  sending small IP frames (= packets).  This keeps tiny telnet and
+  rlogin packets from congesting Wide Area Networks.  Most people
+  strongly recommend to say N here, thereby leaving NAGLE
+  enabled. Those programs that would benefit from disabling this
+  facility can do it on a per connection basis themselves.
+
+IP: Drop source routed frames
+CONFIG_IP_NOSR
+  Usually, the originator of an IP frame (= packet) specifies only the
+  destination, and the hosts along the way do the routing, i.e. they
+  decide how to forward the frame. However, there is a feature of the
+  IP protocol that allows to specify the full route for a given frame
+  already at its origin. A frame with such a fully specified route is
+  called "source routed". The question now is whether we should honour
+  these route requests when such frames arrive, or if we should
+  drop all those frames instead. Honouring them can introduce security
+  problems (and is rarely a useful feature), and hence it is recommended
+  that you say Y here unless you really know what you're doing.
+
+IP: Allow large windows (not recommend if <16Mb of memory)
+CONFIG_SKB_LARGE
+  On high speed, long distance networks the performance limit on 
+  networking becomes the amount of data a machine can buffer until the
+  other end confirms its reception. (At 45Mbit/second there are a lot
+  of bits between New York and London ..). This option allows larger
+  amounts of data to be "in flight" at a given time. It also means a user
+  process can require a lot more memory for network buffers and thus this
+  option is best only used on machines with 16Mb of memory or higher. 
+  Unless you are using long links with end to end speeds of over 2Mbit
+  a second or   satellite links this option will make no difference to
+  performance.
+
+The IPX protocol
+CONFIG_IPX
+  This is support for the Novell networking protocol, IPX, commonly
+  used for local networks of Windows machines. You need it if you want
+  to access Novell Netware file or print servers using the Linux
+  Novell client ncpfs (available via ftp (user: anonymous) from
+  sunsite.unc.edu:/pub/Linux/system/Filesystems/) or from within the
+  Linux DOS emulator dosemu (read the DOSEMU-HOWTO, available in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO). In order to do the former,
+  you'll also have to say Y to "NCP filesystem support", below. To
+  turn your Linux box into a fully featured Netware file server and
+  IPX router, say Y here and fetch either lwared from
+  sunsite.unc.edu:/pub/Linux/system/Network/daemons/ or mars_nwe from
+  ftp.gwdg.de:/pub/linux/misc/ncpfs. For more information, read the
+  IPX-HOWTO in sunsite.unc.edu:/pub/Linux/docs/howto. The IPX driver
+  would enlarge your kernel by about 5 kB. This driver is also
+  available as a module ( = code which can be inserted in and removed
+  from the running kernel whenever you want). If you want to compile
+  it as a module, say M here and read Documentation/modules.txt.
+  Unless you want to integrate your Linux box with a local Novell
+  network, say N.
+
+Full internal IPX network
+CONFIG_IPX_INTERN
+  The full internal IPX network enables you to allocate sockets on
+  different virtual nodes of the internal network. This is done by
+  evaluating the field sipx_node of the socket address given to the bind
+  call. So applications should always initialize the node field to 0
+  when binding a socket on the primary network. In this case the socket
+  is assigned the default node that has been given to the kernel when
+  the internal network was created.
+  By enabling the full internal IPX network the cross-forwarding of
+  packets targeted at 'special' sockets to sockets listening on the
+  primary network is disabled. This might break existing applications,
+  especially RIP/SAP daemons. A RIP/SAP daemon that works well with the
+  full internal net can be found on ftp.gwdg.de:/pub/linux/misc/ncpfs.
+  If you don't know what you are doing, say N.
+
+Appletalk DDP
+CONFIG_ATALK
+  Appletalk is the way Apple computers speak to each other on a
+  network. EtherTalk is the name used for appletalk over ethernet and
+  Localtalk is appletalk over the apple serial links. If your linux box 
+  is connected to such a network and you want to join the conversation,
+  say Y. You will need to use the netatalk package so that your Linux
+  box can act as a print and file server for macs as well as access
+  appletalk printers. Check out
+  http://artoo.hitchcock.org/~flowerpt/projects/linux-netatalk/ on the
+  WWW for details (to browse the WWW, you need to have access to a
+  machine on the Internet that has one of the programs lynx, netscape
+  or Mosaic). The NET-2-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO contains valuable information
+  as well. This driver is also available as a module ( = code which
+  can be inserted in and removed from the running kernel whenever you
+  want). If you want to compile it as a module, say M here and read
+  Documentation/modules.txt. I hear that the GNU boycott of Apple is
+  over, so even politically correct people are allowed to say Y here.
+  At the time the kernel is released the localtalk drivers are not
+  yet ready to ship. The kernel however supports localtalk and when
+  such drivers become available all you will need to do is download
+  and install the localtalk driver.
+
+Amateur Radio AX.25 Level 2
+CONFIG_AX25
+  This is the protocol used for computer communication over amateur
+  radio. It is either used by itself for point-to-point links, or to
+  carry other protocols such as tcp/ip. To use it, you need a device
+  that connects your Linux box to your amateur radio. You can either
+  use a low speed TNC (a Terminal Node Controller acts as a kind of
+  modem connecting your computer's serial port to your radio's
+  microphone input and speaker output) supporting the KISS protocol or
+  the various SCC cards that are supported by the Ottawa PI, the
+  Gracilis Packetwin and the generic Z8530 driver. Another option are
+  the Baycom modem serial and parallel port hacks (supported by their
+  own driver) and the other baycom cards (SCC) (supported by the Z8530
+  driver).  Information about where to get supporting software for
+  Linux amateur radio as well as information about how to configure an
+  AX.25 port is contained in the HAM-HOWTO, available via ftp (user:
+  anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO. You might also
+  want to check out the file Documentation/networking/ax25.txt in the
+  kernel source. More information about digital amateur radio in
+  general is on the WWW at
+  http://www.cis.ohio-state.edu/hypertext/faq/usenet/radio/ham-radio/digital-faq/faq.html
+  (To browse the WWW, you need to have access to a machine on the
+  Internet that has one of the programs lynx, netscape or Mosaic).
+
+Amateur Radio NET/ROM
+CONFIG_NETROM
+  NET/ROM is a network layer protocol on top of AX.25 useful for
+  routing.  A comprehensive listing of all the software for Linux
+  amateur radio users as well as information about how to configure an
+  AX.25 port is contained in the HAM-HOWTO, available via ftp (user:
+  anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO. You also might
+  also want to check out the file
+  Documentation/networking/ax25.txt. More information about digital
+  amateur radio in general is on the WWW at
+  http://www.cis.ohio-state.edu/hypertext/faq/usenet/radio/ham-radio/digital-faq/faq.html
+  (To browse the WWW, you need to have access to a machine on the
+  Internet that has one of the programs lynx, netscape or
+  Mosaic). 
+
+AX.25 over Ethernet
+CONFIG_BPQETHER
+  AX.25 is the protocol used for computer communication over amateur
+  radio. If you say Y here, you will be able to send and receive AX.25
+  traffic over ethernet (also called "BPQ AX.25"), which could be
+  useful if some other computer on your local network has a direct
+  amateur radio connection.
+
+Bridging (EXPERIMENTAL)
+CONFIG_BRIDGE
+  If you say Y here, then your Linux box will be able to act as an
+  ethernet bridge, which means that the different ethernet segments it
+  is connected to will appear as one ethernet to the
+  participants. Several such bridges can work together to create even
+  larger networks of ethernets using the IEEE802.1 spanning tree
+  algorithm. As this is a standard, Linux bridges will interwork
+  properly with other third party bridge products. In order to use
+  this, you'll need the bridge configuration tools available via ftp
+  (user: anonymous) from shadow.cabi.net. Note that if your box acts
+  as a bridge, it probably contains several ethernet devices, but the
+  kernel is not able to recognize more than one at boot time without
+  help; for details read the Multiple-Ethernet-mini-HOWTO, available
+  via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini. The Bridging code is
+  still in test. If unsure, say N.
+
+Kernel/User network link driver (EXPERIMENTAL)
+CONFIG_NETLINK
+  This driver allows for two-way communication between certain parts
+  of the kernel or modules and user processes; the user processes are
+  able to read from and write to character special files in the /dev
+  directory having major mode 36. So far, the kernel uses it to
+  publish some network related information if you enable "Routing
+  messages", below. Say Y if you want to experiment with it; this is
+  EXPERIMENTAL code, which means that it need not be completely stable.
+  You need to include this if you want to use arpd, a daemon that
+  helps keep the internal ARP cache (a mapping between IP addresses
+  and hardware addresses on the local network) small. If unsure, say
+  N.
+
+Routing messages
+CONFIG_RTNETLINK
+  If you enable this and create a character special file /dev/route
+  with major number 36 and minor number 0 using mknod ("man mknod"),
+  you can read some network related routing information from that
+  file. Everything you write to that file will be discarded.
+
+SCSI support?
+CONFIG_SCSI
+  If you want to use a SCSI harddisk, SCSI tapedrive, SCSI CDROM or
+  any other SCSI device under Linux, say Y and make sure that you know
+  the name of your SCSI host adaptor (the card inside your computer
+  that "speaks" the SCSI protocol), because you will be asked for
+  it. You also need to say Y here if you want support for the parallel
+  port version of the 100MB IOMEGA ZIP drive. Please read the
+  SCSI-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  This driver is also
+  available as a module ( = code which can be inserted in and removed
+  from the running kernel whenever you want). If you want to compile
+  it as a module, say M here and read Documentation/modules.txt and
+  Documentation/scsi.txt.
+
+SCSI disk support
+CONFIG_BLK_DEV_SD
+  If you want to use a SCSI harddisk or the SCSI or parallel port
+  version of the IOMEGA ZIP drive under Linux, say Y and read the
+  SCSI-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This is NOT for SCSI
+  CDROMs. This driver is also available as a module ( = code which can
+  be inserted in and removed from the running kernel whenever you
+  want). If you want to compile it as a module, say M here and read
+  Documentation/modules.txt and Documentation/scsi.txt.
+  
+SCSI tape support
+CONFIG_CHR_DEV_ST
+  If you want to use a SCSI tapedrive under Linux, say Y and read the
+  SCSI-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO and drivers/scsi/README.st in
+  the kernel source. This is NOT for SCSI CDROMs. This driver is also
+  available as a module ( = code which can be inserted in and removed
+  from the running kernel whenever you want). If you want to compile
+  it as a module, say M here and read Documentation/modules.txt and
+  Documentation/scsi.txt .
+
+SCSI CDROM support
+CONFIG_BLK_DEV_SR
+  If you want to use a SCSI CDROM under Linux, say Y and read the
+  SCSI-HOWTO and the CDROM-HOWTO from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. Also make sure to enable the
+  ISO9660 filesystem later. This driver is also available as a module
+  ( = code which can be inserted in and removed from the running
+  kernel whenever you want). If you want to compile it as a module,
+  say M here and read Documentation/modules.txt and
+  Documentation/scsi.txt .
+
+Enable vendor-specific extentions (for SCSI CDROM)
+CONFIG_BLK_DEV_SR_VENDOR
+  This enables the usage of vendor specific SCSI commands. This is
+  required for some stuff which is newer than the SCSI-II standard,
+  most important is the multisession CD support. You'll probably want
+  to say y here, unless you have a _real old_ CD-ROM drive.
+
+SCSI generic support
+CONFIG_CHR_DEV_SG
+  If you want to use SCSI scanners, synthesizers or CD-writers or just
+  about anything having "SCSI" in its name other than harddisks,
+  CDROMs or tapes, say Y here. Those won't be supported by the kernel
+  directly, so you need some additional software which knows how to
+  talk to these devices using the SCSI protocol. For CD-writers, you
+  would need the program cdwrite, available via ftp (user: anonymous)
+  from sunsite.unc.edu:/pub/Linux/utils/disk-management; for other
+  devices, it's possible that you'll have to write the driver software
+  yourself, so have a look at the SCSI-HOWTO and at the
+  SCSI-Programming-HOWTO, both available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. If you want to compile this
+  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 and Documentation/scsi.txt.
+
+Probe all LUNs on each SCSI device
+CONFIG_SCSI_MULTI_LUN
+  If you have a SCSI device that supports more than one LUN (Logical
+  Unit Number), e.g. a CD jukebox, you should say Y here so that all
+  will be found by the SCSI driver. An SCSI device with multiple LUNs
+  acts logically like multiple SCSI devices. The vast majority of SCSI
+  devices have only one LUN, and so most people can say N here and
+  should in fact do so, because it is safer.
+
+Verbose SCSI error reporting (kernel size +=12K)
+CONFIG_SCSI_CONSTANTS
+  The error messages regarding your SCSI hardware will be easier to
+  understand if you enable this; it will enlarge your kernel by about
+  12KB. If in doubt, say Y.
+
+AdvanSys SCSI support
+CONFIG_SCSI_ADVANSYS
+  This is a driver for all SCSI host adaptors manufactured by
+  AdvanSys. It is documented in the kernel source in
+  drivers/scsi/advansys.c. This driver is also available as a module (
+  = code which can be inserted in and removed from the running kernel
+  whenever you want). If you want to compile it as a module, say M
+  here and read Documentation/modules.txt.
+
+Adaptec AHA152X/2825 support
+CONFIG_SCSI_AHA152X
+  This is support for the AHA-1510, AHA-1520, AHA-1522, and AHA-2825
+  SCSI host adaptors. It is explained in section 3.3 of the
+  SCSI-HOWTO, available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. You might also want to read
+  the comments at the top of drivers/scsi/aha152x.c. This driver is
+  also available as a module ( = code which can be inserted in and
+  removed from the running kernel whenever you want). If you want to
+  compile it as a module, say M here and read
+  Documentation/modules.txt.
+
+Adaptec AHA1542 support
+CONFIG_SCSI_AHA1542
+  This is support for a SCSI host adaptor. It is explained in section
+  3.4 of the SCSI-HOWTO, available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  Note that Trantor was
+  recently purchased by Adaptec, and some former Trantor products are
+  being sold under the Adaptec name. If it doesn't work out of
+  the box, you may have to change some settings in
+  drivers/scsi/aha1542.h.  If you want to compile this 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.
+ 
+Adaptec AHA1740 support
+CONFIG_SCSI_AHA1740
+  This is support for a SCSI host adaptor. It is explained in section
+  3.5 of the SCSI-HOWTO, available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If it doesn't work out of
+  the box, you may have to change some settings in
+  drivers/scsi/aha1740.h. This driver is also available as a module (
+  = code which can be inserted in and removed from the running kernel
+  whenever you want). If you want to compile it as a module, say M
+  here and read Documentation/modules.txt.
+
+Adaptec AHA274X/284X/294X support
+CONFIG_SCSI_AIC7XXX
+  Information about this SCSI host adaptor is contained in
+  drivers/scsi/README.aic7xxx and in the SCSI-HOWTO, available via ftp
+  (user: anonymous) at sunsite.unc.edu:/pub/Linux/docs/HOWTO. If it
+  doesn't work out of the box, you may have to change some settings in
+  drivers/scsi/aic7xxx.h.  If you want to compile this 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.
+
+BusLogic SCSI support
+CONFIG_SCSI_BUSLOGIC
+  This is support for BusLogic MultiMaster SCSI Host Adaptors.
+  Consult the SCSI-HOWTO, available via anonymous ftp from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO and the file
+  drivers/scsi/README.BusLogic for more information. BusLogic
+  FlashPoint SCSI Host Adapters are not supported by this driver, but
+  BusLogic has initiated an upgrade program which allows you to get a
+  better adaptor for few $$. Read about it in
+  drivers/scsi/README.FlashPoint.  If this driver does not work
+  correctly without modification, please contact the author.  You can
+  build this driver also as a module ( = code which can be inserted in
+  and removed from the running kernel whenever you want), but only a
+  single instance may be loaded. If you want to compile it as a
+  module, say M here and read Documentation/modules.txt.
+
+DTC3180/3280 SCSI support
+CONFIG_SCSI_DTC3280
+  This is support for DTC 3180/3280 SCSI Host Adaptors.  Please read
+  the SCSI-HOWTO, available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO and the file
+  drivers/scsi/README.dtc3x80.  This driver is also available as a
+  module (= code which can be inserted in and removed from the running
+  kernel whenever you want). If you want to compile it as a module,
+  say M here and read Documentation/modules.txt.
+
+EATA-DMA (DPT, NEC, AT&T, SNI, AST, Olivetti, Alphatronix) support
+CONFIG_SCSI_EATA_DMA
+  This is support for the EATA-DMA protocol compliant SCSI Host
+  Adaptors like the SmartCache III/IV, SmartRAID controller families
+  and the DPT PM2011B and PM2012B controllers.  Please read the
+  SCSI-HOWTO, available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  This driver is also
+  available as a module (= code which can be inserted in and removed
+  from the running kernel whenever you want). If you want to compile
+  it as a module, say M here and read Documentation/modules.txt.
+
+EATA-PIO (old DPT PM2001, PM2012A) support
+CONFIG_SCSI_EATA_PIO
+  This driver supports all EATA-PIO protocol compliant SCSI Host
+  Adaptors like the DPT PM2001 and the PM2012A. EATA-DMA compliant
+  host adaptors could also use this driver but are discouraged from
+  doing so, since this driver only supports harddisks and lacks
+  numerous features.  You might want to have a look at the SCSI-HOWTO,
+  available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If you want to compile this
+  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.
+
+UltraStor 14F/34F support
+CONFIG_SCSI_U14_34F
+  This is support for the UltraStor 14F and 34F SCSI-2 host adapters.
+  The source at drivers/scsi/u14-34f.c contains some information about 
+  this hardware. If the driver doesn't work out of the box, you may have 
+  to change some settings in drivers/scsi/u14-34f.c.
+  Read the SCSI-HOWTO, available via ftp (user: anonymous) at 
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. Note that there is also another
+  driver for the same hardware: "UltraStor SCSI support", below.
+  You should enable both only if you want 24F support as well. This
+  driver is also available as a module ( = code which can be inserted
+  in and removed from the running kernel whenever you want). If you
+  want to compile it as a module, say M here and read
+  Documentation/modules.txt.
+
+Future Domain 16xx SCSI support
+CONFIG_SCSI_FUTURE_DOMAIN
+  This is support for Future Domain's 16-bit SCSI host adaptors
+  (TMC-1660/1680, TMC-1650/1670, TMC-3260, TMC-1610M/MER/MEX) and other
+  adaptors based on the Future Domain chipsets (Quantum ISA-200S,
+  ISA-250MG; Adaptec AHA-2920; and at least one IBM board).  It is
+  explained in section 3.7 of the SCSI-HOWTO, available via ftp (user:
+  anonymous) at sunsite.unc.edu:/pub/Linux/docs/HOWTO.  This driver is
+  also available as a module ( = code which can be inserted in and
+  removed from the running kernel whenever you want). If you want to
+  compile it as a module, say M here and read Documentation/modules.txt.
+
+Generic NCR5380/53c400 SCSI support
+CONFIG_SCSI_GENERIC_NCR5380
+  This is the generic NCR family of SCSI controllers, not to be
+  confused with the NCR 53c7 or 8xx controllers. It is explained in
+  section 3.8 of the SCSI-HOWTO, available via ftp (user: anonymous)
+  at sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If it doesn't work out of
+  the box, you may have to change some settings in
+  drivers/scsi/g_NCR5380.h. This driver is also available as a module
+  ( = code which can be inserted in and removed from the running
+  kernel whenever you want). If you want to compile it as a module,
+  say M here and read Documentation/modules.txt.
+ 
+Enable NCR53c400 extensions
+CONFIG_SCSI_GENERIC_NCR53C400
+  This enables certain optimizations for the NCR53c400 scsi cards. You
+  might as well try it out. Note that this driver will only probe for
+  the Trantor T130B in its default configuration; you might have to
+  pass a command line option to the kernel at boot time if it doesn't
+  detect your card. See the file drivers/scsi/README.g_NCR5380 for
+  details. If you want to compile it as a module, say M here and read
+  Documentation/modules.txt.
+
+NCR5380/53c400 mapping method (use Port for T130B)
+CONFIG_SCSI_G_NCR5380_PORT
+  The NCR5380 and NCR53c400 SCSI controllers come in two varieties:
+  port or memory mapped. You should know what you have. The most
+  common card, Trantor T130B, uses port mapped mode.
+
+NCR53c7,8xx SCSI support
+CONFIG_SCSI_NCR53C7xx
+  This is the 53c7 and 8xx NCR family of SCSI controllers, not to be
+  confused with the NCR 5380 controllers. It is explained in section
+  3.8 of the SCSI-HOWTO, available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. If it doesn't work out of the
+  box, you may have to change some settings in
+  drivers/scsi/53c7,8xx.h. This driver is also available as a module (
+  = code which can be inserted in and removed from the running kernel
+  whenever you want). If you want to compile it as a module, say M
+  here and read Documentation/modules.txt.
+
+always negotiate synchronous transfers
+CONFIG_SCSI_NCR53C7xx_sync
+  In general, this is good; however, it is a bit dangerous since there
+  are some broken SCSI devices out there. Take your chances. Safe bet
+  is N.
+
+allow FAST-SCSI [10MHz]
+CONFIG_SCSI_NCR53C7xx_FAST
+  This will enable 10MHz FAST-SCSI transfers with your host
+  adaptor. Some systems have problems with that speed, so it's safest
+  to say N here.
+ 
+allow DISCONNECT
+CONFIG_SCSI_NCR53C7xx_DISCONNECT
+  This enables the disconnect/reconnect feature of the NCR SCSI
+  controller.  When this is enabled, a slow SCSI device will not lock
+  the SCSI bus while processing a request, allowing simultaneous use
+  of e.g. a SCSI hard disk and SCSI tape or CD-ROM drive, and
+  providing much better performance when using slow and fast SCSI
+  devices at the same time. Some devices, however, do not operate
+  properly with this option enabled, and will cause your SCSI system
+  to hang, which might cause a system crash.  The safe answer
+  therefore is to say N.
+
+NCR53C8XX SCSI support
+CONFIG_SCSI_NCR53C8XX
+  This is the BSD ncr driver adapted to linux for the NCR53C8XX family
+  of PCI-SCSI controllers. This driver supports parity checking,
+  tagged command queuing, fast scsi II transfer up to 10 MB/s with
+  narrow scsi devices and 20 MB/s with wide scsi devices.
+  Linux/i386 and Linux/Alpha are supported by this driver.
+  Memory mapped io is currently untested under Linux/Alpha.
+  Please read drivers/scsi/README.ncr53c8xx for more information.
+
+synchronous data transfers frequency
+CONFIG_SCSI_NCR53C8XX_SYNC
+  SCSI-2 specifications allow scsi devices to negotiate a synchronous 
+  transfer period of 25 nano-seconds or more.
+  The transfer period value is 4 times the agreed transfer period.
+  So, data can be transferred at a 10 MHz frequency, allowing 10 MB/second 
+  throughput with 8 bits scsi-2 devices and 20 MB/second with wide16 devices.
+  This frequency can be used safely with differential devices but may cause 
+  problems with singled-ended devices.
+  Specify 0 if you want to only use asynchronous data transfers.
+  Otherwise, specify a value between 5 and 10.
+  Commercial O/Ses generally use 5 Mhz frequency for synchronous transfers.
+  It is a reasonnable default value.
+  However, a flawless singled-ended scsi bus supports 10 MHz data transfers.
+  Regardless the value choosen in the Linux configuration, the synchronous 
+  period can be changed after boot-up through the /proc/scsi file system.
+  The generic command is:
+      echo "setsync #target period" >/proc/scsi/ncr53c8xx/0
+  Use a 25 ns period for 10 Mhz synchronous data transfers.
+
+use normal IO
+CONFIG_SCSI_NCR53C8XX_IOMAPPED
+  Warning! Under linux/Alpha only normal io has been currently tested.
+  This option allows you to force the driver to use normal IO.
+  Memory mapped IO has less latency than normal IO and works for most 
+  Intel-based hardware.
+  The normal answer therefore is N.
+
+not allow targets to disconnect
+CONFIG_SCSI_NCR53C8XX_NO_DISCONNECT
+  This option is only provided for safety if you suspect some scsi
+  device of yours to not support properly the target-disconnect
+  feature. In that case, you would say Y here. In general however, to
+  not allow targets to disconnect is not reasonable if there is more
+  than 1 device on a scsi bus.  The normal answer therefore is N.
+
+enable tagged command queuing
+CONFIG_SCSI_NCR53C8XX_TAGGED_QUEUE
+  This option allows you to enable tagged command queuing support at
+  linux start-up.  Some scsi devices do not properly support this
+  feature.  The suggested method is to say N here and to use the
+  "settags" control command after boot-up to enable this feature:
+      echo "settags 2 4" >/proc/scsi/ncr53c8xx/0
+  asks the driver to use up to 4 concurrent tagged commands for target
+  2 of controller 0.
+  See the file drivers/scsi/README.ncr53c8xx for more information.
+  WARNING! If you say Y here, then you have to say N to "not allow
+  targets to disconnect", above.
+  The safe answer therefore is N.
+  The normal answer therefore is Y.
+
+maximum number of queued commands
+CONFIG_SCSI_NCR53C8XX_MAX_TAGS
+  This option allows you to specify the maximum number of commands that 
+  can be queud to a device, when tagged command queuing is possible.
+  The default value is 4. Minimum is 2, maximum is 12.
+  The normal answer therefore is the default one.
+
+force synchronous negotiation
+CONFIG_SCSI_NCR53C8XX_FORCE_SYNC_NEGO
+  Some scsi-2 devices support synchronous negotiations but do not
+  report this feature in byte 7 of inquiry data.
+  Answer Y only if you suspect some device to be so humble.
+  The normal answer therefore is N.
+ 
+disable master parity checking
+CONFIG_SCSI_NCR53C8XX_DISABLE_MPARITY_CHECK
+  Some hardware may have problems with parity during master cycles on
+  PCI bus.  Only seen once. Answer Y if you suspect such problem.  The
+  normal answer therefore is N.
+
+disable scsi parity checking
+CONFIG_SCSI_NCR53C8XX_DISABLE_PARITY_CHECK
+  Parity on scsi bus is a system option. If one device checks parity,
+  then all devices on the scsi bus must generate parity.  However, the
+  parity can be ignored by the scsi devices.  Answer Y only if you
+  know what you are doing.  The normal answer therefore is N.
+
+Always IN2000 SCSI support
+CONFIG_SCSI_IN2000
+  This is support for an ISA bus SCSI host adaptor. You'll find
+  more information in drivers/scsi/in2000.readme. If it doesn't
+  work out of the box, you may have to change the jumpers for IRQ
+  or address selection. If you want to compile this 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.
+
+PAS16 SCSI support
+CONFIG_SCSI_PAS16
+  This is support for a SCSI host adaptor. It is explained in section
+  3.10 of the SCSI-HOWTO, available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. If it doesn't work out of the
+  box, you may have to change some settings in drivers/scsi/pas16.h.
+ 
+Qlogic FAS SCSI support
+CONFIG_SCSI_QLOGIC_FAS
+  This driver works only with the ISA, VLB, and PCMCIA versions of the
+  Qlogic FastSCSI! cards as well as any other card based on the FASXX
+  chip (including the Control Concepts SCSI/IDE/SIO/PIO/FDC cards); it
+  does NOT support the PCI version. The PCI versions are supported by
+  the Qlogic ISP driver though.  Information about this driver is
+  contained in drivers/scsi/README.qlogicfas.  You should also read
+  the SCSI-HOWTO, available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt.
+
+Qlogic ISP SCSI support (EXPERIMENTAL)
+CONFIG_SCSI_QLOGIC_ISP
+  This driver works for all QLogic PCI SCSI host adaptors (IQ-PCI,
+  IQ-PCI-10, IQ_PCI-D) except for the PCI-basic card. (This latter
+  card is supported by the "AM53/79C974 PCI SCSI" driver). If you say
+  Y here, make sure to say Y to "PCI BIOS support" as well. More
+  information is contained in the file
+  drivers/scsi/README.qlogicisp. You should also read the SCSI-HOWTO,
+  available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt.
+
+Seagate ST-02 and Future Domain TMC-8xx SCSI support
+CONFIG_SCSI_SEAGATE
+  These are 8-bit SCSI controllers; the ST-01 is also supported by this
+  driver.  It is explained in section 3.9 of the SCSI-HOWTO, available
+  via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. If it doesn't work out of the
+  box, you may have to change some settings in drivers/scsi/seagate.h.
+  This driver is also available as a module ( = code which can be
+  inserted in and removed from the running kernel whenever you
+  want). If you want to compile it as a module, say M here and read
+  Documentation/modules.txt.
+
+Trantor T128/T128F/T228 SCSI support
+CONFIG_SCSI_T128
+  This is support for a SCSI host adaptor. It is explained in section
+  3.11 of the SCSI-HOWTO, available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If it doesn't work out of
+  the box, you may have to change some settings in
+  drivers/scsi/t128.h. Note that Trantor was recently purchased by
+  Adaptec, and some former Trantor products are being sold under the
+  Adaptec name.
+
+UltraStor SCSI support
+CONFIG_SCSI_ULTRASTOR
+  This is support for the UltraStor 14F, 24F and 34F SCSI-2 host
+  adaptor family. This driver is explained in section 3.12 of the
+  SCSI-HOWTO, available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. If it doesn't work out of the
+  box, you may have to change some settings in
+  drivers/scsi/ultrastor.h. If you want to compile this 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.
+  Note that there is also another driver for UltraStor hardware:
+  "UltraStor 14F/34F support", above.
+ 
+7000FASST SCSI support
+CONFIG_SCSI_7000FASST
+  This driver supports the Western Digital 7000 SCSI host adaptor.
+  Some information is in the source: drivers/scsi/wd7000.c.  This
+  driver is also available as a module ( = code which can be inserted
+  in and removed from the running kernel whenever you want). If you
+  want to compile it as a module, say M here and read
+  Documentation/modules.txt.
+
+EATA ISA/EISA/PCI (DPT and generic EATA/DMA-compliant boards) support
+CONFIG_SCSI_EATA
+  This driver supports all the EATA/DMA-compliant SCSI host adapters
+  and does not need any BIOS32 service.
+  DPT ISA and all EISA i/o addresses are probed looking for the "EATA"
+  signature. If "PCI bios support" is enabled, the addresses of all the
+  PCI SCSI controllers reported by BIOS32 are probed as well.
+  Note that there is also another driver for the same hardware:
+  "EATA-DMA support". You should enable only one of them.
+  You want to read the start of drivers/scsi/eata.c and the
+  SCSI-HOWTO, available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If you want to compile this
+  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.
+
+NCR53c406a SCSI support
+CONFIG_SCSI_NCR53C406A
+  This is support for the NCR53c406a SCSI host adapter. For user
+  configurable parameters, check out drivers/scsi/NCR53c406.c in the
+  kernel source. Also read the SCSI-HOWTO, available via ftp (user:
+  anonymous) at sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If you want 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.
+
+AM53/79C974 PCI SCSI support
+CONFIG_SCSI_AM53C974
+  This is support for the AM53/79C974 SCSI host adapters. Please read
+  drivers/scsi/README.AM53C974 for details. Also, the SCSI-HOWTO,
+  available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO, is for you.
+
+IOMEGA Parallel Port ZIP drive SCSI support
+CONFIG_SCSI_PPA
+  This driver supports the parallel port version of IOMEGA's ZIP drive
+  (a 100Mb removable media device).  For more information about this
+  driver and how to use it you should read the file
+  drivers/scsi/README.ppa.  You should also read the SCSI-HOWTO, which
+  is available via anonymous ftp from sunsite.unc.edu in the directory
+  /pub/Linux/docs/HOWTO.  This driver is also available as a module
+  which can be inserted in and removed from the running kernel
+  whenever you want. If you want to use any two of a parallel port ZIP
+  drive, a parallel printer or PLIP on the same parallel port, you
+  should compile the drivers as modules and only insert them as
+  needed. To compile this driver as a module, say M here and read
+  Documentation/modules.txt. Note that you can say N here if you have
+  the SCSI version of the ZIP drive: it will be supported
+  automatically if you enabled the generic "SCSI disk support", above.
+
+Network device support?
+CONFIG_NETDEVICES
+  You can say N here in case you don't intend to connect to any other
+  computer at all or all your connections will be either via UUCP
+  (UUCP is a protocol to forward mail and news between unix hosts over
+  telephone lines; read the UUCP-HOWTO, available via ftp (user:
+  anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO) or dialing up a
+  shell account or a BBS, even using term (term is a program which
+  gives you almost full Internet connectivity if you have a regular
+  dial up shell account on some Internet connected Unix computer. Read
+  the Term-HOWTO).  You'll have to say Y if your computer contains a
+  network card that you want to use under linux (make sure you know
+  its name because you will be asked for it and read the
+  Ethernet-HOWTO; also, if you plan to use more than one network card
+  under linux, read the Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini) or if you want to use
+  SLIP (Serial Line Internet Protocol is the protocol used to send
+  Internet traffic over telephone lines or nullmodem cables) or CSLIP
+  (compressed SLIP) or PPP (better and newer variant of SLIP) or PLIP
+  (Parallel Line Internet Protocol is mainly used to create a mini
+  network by connecting the parallel ports of two local machines) or
+  AX.25/KISS (protocol for sending internet traffic over radio links).
+  Make sure to read the NET-2-HOWTO.  Eventually, you will have to
+  read Olaf Kirch's excellent book "Network Administrator's Guide", to
+  be found in sunsite.unc.edu:/pub/Linux/docs/LDP.  If unsure, say Y.
+
+CONFIG_NET_ETHERNET
+  Ethernet is the most common protocol used on Local Area Networks
+  (LANs) in universities or companies. 10-base-2 and 10-base-T and
+  100-base-<whatever> are common types of ethernet. If your Linux
+  machine will be connected to an Ethernet and you have an ethernet
+  network card installed in your computer, say Y here and read the
+  Ethernet-HOWTO, available via ftp (user: anonymous) from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  Note that the answer to this
+  question won't directly affect the kernel: saying N will just cause
+  this configure script to skip all the questions about Ethernet
+  network cards. If unsure, say N.
+
+Dummy net driver support
+CONFIG_DUMMY
+  This is essentially a bit-bucket device (i.e. traffic you send to
+  this device is consigned into oblivion) with a configurable IP
+  address. It is most commonly used in order to make your currently
+  inactive SLIP address seem like a real address for local
+  programs. If you use SLIP or PPP, you might want to enable it. Read
+  about it in the Network Administrator's Guide, available via ftp
+  (user: anonymous) from sunsite.unc.edu:/pub/Linux/docs/LDP. Since
+  this thing comes often handy, the default is Y. It won't enlarge
+  your kernel either. What a deal.  If you want to compile this 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. If you want to use more than one dummy
+  device at a time, you need to compile it as a module. Instead of
+  'dummy', it will they will then be called 'dummy0', 'dummy1' etc.
+  
+SLIP (serial line) support
+CONFIG_SLIP
+  Say Y if you intend to use SLIP or CSLIP (compressed SLIP) to
+  connect to your Internet service provider or to connect to some
+  other local Unix box or if you want to configure your Linux box as a
+  Slip/CSlip server for other people to dial in.  SLIP (Serial Line
+  Internet Protocol) is the protocol used to send Internet traffic
+  over telephone lines or serial cables (also known as
+  nullmodems). Normally, your access provider has to support SLIP in
+  order for you to be able to use it, but there is now a SLIP emulator
+  called SLiRP around (available via ftp (user: anonymous) from
+  sunsite.unc.edu:/pub/Linux/system/Network/serial/) which allows you
+  to use SLIP over a regular dial up shell connection. If you plan to
+  use SLiRP, make sure to say Y to CSLIP, below. The NET-2-HOWTO,
+  available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO, explains how to configure
+  SLIP. Note that you don't need this option if you just want to run
+  term (term is a program which gives you almost full Internet
+  connectivity if you have a regular dial up shell account on some
+  Internet connected Unix computer. Read the Term-HOWTO). SLIP support
+  will enlarge your kernel by about 4kB. If unsure, say N.  If you
+  want to compile this 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 as well as
+  Documentation/networking/net-modules.txt.
+  
+CSLIP compressed headers
+CONFIG_SLIP_COMPRESSED
+  This protocol is faster than SLIP because it uses compression on the
+  TCP/IP headers (not on the data itself), but it has to be supported
+  on both ends. Ask your access provider if you are not sure and say
+  Y, just in case. You will still be able to use plain SLIP. If you
+  plan to use SLiRP, the SLIP emulator (available via ftp (user:
+  anonymous) from sunsite.unc.edu:/pub/Linux/system/Network/serial/)
+  which allows you to use SLIP over a regular dial up shell
+  connection, you definitely want to say Y here. The NET-2-HOWTO,
+  available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO, explains how to configure
+  CSLIP. This won't enlarge your kernel.
+
+Keepalive and linefill
+CONFIG_SLIP_SMART
+  Adds additional capabilities to the SLIP driver to support the
+  RELCOM line fill and keepalive monitoring. Ideal on poor quality
+  analogue lines.
+
+Six bit SLIP encapsulation
+CONFIG_SLIP_MODE_SLIP6
+  Just occasionally you may need to run IP over hostile serial
+  networks that don't pass all control characters or are only seven
+  bit. Saying Y here adds an extra mode you can use with SLIP:
+  "slip6". In this mode, SLIP will only send normal ascii symbols over
+  the serial device. Naturally, this has to be supported at the other
+  end of the link as well. It's good enough, for example, to run IP
+  over the async ports of a Camtec JNT Pad. If unsure, say N.
+
+Radio network interfaces
+CONFIG_NET_RADIO
+  Radio based interfaces for Linux. This includes amateur radio
+  (AX.25), support for wireless ethernet and other systems. Note that
+  the answer to this question won't directly affect the kernel:
+  saying N will just cause this configure script to skip all the
+  questions about radio interfaces. Some user-level drivers for scarab
+  devices which don't require special kernel support are available via
+  ftp (user: anonymous) from shadow.cabi.net. If unsure, say N.
+
+PPP (point-to-point) support
+CONFIG_PPP
+  PPP (Point to Point Protocol) is a newer and better SLIP. It serves
+  the same purpose: sending Internet traffic over telephone (and other
+  serial) lines.  Ask your access provider if they support it, because
+  otherwise you can't use it (not quite true any more: the free
+  program SLiRP can emulate a PPP line if you just have a regular dial
+  up shell account on some UNIX computer; get it via ftp (user:
+  anonymous) from sunsite.unc.edu:/pub/Linux/system/Network/serial/).
+  To use PPP, you need an additional program called pppd as described
+  in Documentation/networking/ppp.txt and in the PPP-HOWTO, available
+  from sunsite.unc.edu:/pub/Linux/docs/HOWTO. Note that you don't need
+  this option if you just want to run term (term is a program which
+  gives you almost full Internet connectivity if you have a regular
+  dial up shell account on some Internet connected UNIX computer. Read
+  the Term-HOWTO). The PPP option enlarges your kernel by about
+  16kB. This driver is also available as a module ( = code which can
+  be inserted in and removed from the running kernel whenever you
+  want). If you said Y to "Version information on all symbols" above,
+  then you cannot compile the PPP driver into the kernel; you can only
+  compile it as a module. If you want to compile it as a module, say M
+  here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. Note that, no matter what
+  you do, the BSD compression code (used to compress the IP packets
+  sent over the serial line; has to be supported at the other end as
+  well) can only be compiled as a module; it is called bsd_comp.o and
+  will show up in the directory modules once you have said "make
+  modules". If unsure, say N.
+
+16 channels instead of 4 
+CONFIG_PPP_LOTS
+  Saying Y here will allow you to have up to 16 PPP connections
+  running in parallel. This is mainly useful if you intend your linux
+  box to act as a dial-in PPP server. Most people can say N.
+
+STRIP (Starmode Radio IP) support
+CONFIG_STRIP
+  Say Y if you have a Metricom radio and intend to use Starmode Radio
+  IP.  STRIP is a radio protocol developed for the MosquitoNet project
+  (http://mosquitonet.stanford.edu/) to send Internet traffic using
+  Metricom radios.  Metricom radios are small, battery powered,
+  100kbit/sec packet radio transceivers, about the size and weight of
+  a cellular telephone.  (You may also have heard them called
+  "Metricom modems" but we avoid the term "modem" because it misleads
+  many people into thinking that you can plug a Metricom modem into a
+  phone line and use it as a modem.)  You can use STRIP on any Linux
+  machine with a serial port, although it is obviously most useful for
+  people with laptop computers. If you think you might get a Metricom
+  radio in the future, there is no harm in saying yes to STRIP now,
+  except that it makes the kernel a bit bigger.
+
+WIC (Radio IP bridge)
+CONFIG_WIC
+  Support for the WIC parallel port radio bridge. You'll probably want
+  to say N.  If you want to compile this driver as a module though ( =
+  code which can be inserted in and removed from the running kernel
+  whenever you want), say M here and read Documentation/modules.txt.
+
+Z8530 SCC driver for AX.25
+CONFIG_SCC
+  These cards are used to connect your Linux box to an amateur radio
+  in order to communicate with other computers.  If you want to use
+  this, read Documentation/networking/z8530drv.txt and the AX.25-HOWTO,
+  available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If you want to compile this
+  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.
+
+BAYCOM ser12 and par96 driver for AX.25
+CONFIG_BAYCOM
+  This is an experimental driver for Baycom style simple amateur radio
+  modems that connect to either a serial interface or a parallel
+  interface. The driver supports the ser12 and par96 designs. To
+  configure the driver, use the sethdlc utility available
+  in the standard ax25 utilities package. For information on the modems,
+  see http://www.baycom.de and drivers/net/README.baycom.
+  If you want to compile this 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. This is recommended.
+
+Soundcard modem driver for AX.25
+CONFIG_SOUNDMODEM
+  This experimental driver allows a standard SoundBlaster or 
+  WindowsSoundSystem compatible soundcard to be used as a packet radio
+  modem. To configure the driver, use the sethdlc, smdiag and smmixer
+  utilities available in the standard ax25 utilities package. For
+  informations on how to key the transmitter, see
+  http://www.ife.ee.ethz.ch/~sailer/pcf/ptt_circ/ptt.html and
+  drivers/net/README.soundmodem. If you want to compile this 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. This is recommended.
+
+PLIP (parallel port) support
+CONFIG_PLIP
+  PLIP (Parallel Line Internet Protocol) is used to create a mini
+  network consisting of two (or, rarely, more) local machines. The
+  parallel ports (the connectors at the computers with 25 holes) are
+  connected using "null printer" or "Turbo Laplink" cables which can
+  transmit 4 bits at a time or using special PLIP cables, to be used
+  on bidirectional parallel ports only, which can transmit 8 bits at a
+  time (you can find the wiring of these cables in
+  drivers/net/README?.plip). The cables can be up to 15m long. This
+  works also if one of the machines runs DOS/Windows and has some PLIP
+  software installed, e.g. the Crynwr PLIP packet driver
+  (http://sunsite.cnam.fr/packages/Telnet/PC/msdos/misc/pktdrvr.txt)
+  and winsock or NCSA's telnet.  If you want to use this, say Y and
+  read the PLIP mini-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini as well as the
+  NET-2-HOWTO in sunsite.unc.edu:/pub/Linux/docs/HOWTO. Note that the
+  PLIP protocol was changed and this PLIP driver won't work together
+  with the PLIP support in Linux versions 1.0.x.  This option enlarges
+  your kernel by about 8kB. If you want to compile this 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 as
+  well as Documentation/networking/net-modules.txt. If you want to use
+  both a parallel printer and PLIP, there are two cases: 1) If the
+  printer and the PLIP cable are to use the same parallel port
+  (presumably because you have just one), it is best to compile both
+  drivers as modules and load and unload them as needed. 2) To use
+  different parallel ports for the printer and the PLIP cable, you can
+  say Y to the printer driver, specify the base address of the
+  parallel port(s) to use for the printer(s) with the "lp" kernel
+  command line option. (See the documentation of your boot loader
+  (lilo or loadlin) about how to pass options to the kernel at boot
+  time. The lilo procedure is also explained in the SCSI-HOWTO,
+  available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.) The standard base addresses
+  as well as the syntax of the "lp" command line option can be found
+  in drivers/char/lp.c. You can then say Y to this PLIP driver or,
+  preferably, M in which case Documentation/networking/net-modules.txt
+  tells you how to specify the port and IRQ to be used by PLIP at
+  module load time.
+  It's safe to say N here.
+
+EQL (serial line load balancing) support
+CONFIG_EQUALIZER
+  If you have two serial connections to some other computer (this
+  usually requires two modems and two telephone lines) and you use
+  SLIP (= the protocol for sending internet traffic over telephone
+  lines) or PPP (= a better SLIP) on them, you can make them behave
+  like one double speed connection using this driver. Naturally, this
+  has to be supported at the other end as well, either with a similar
+  EQL Linux driver or with a Livingston Portmaster 2e. Say Y if you
+  want this and read drivers/net/README.eql. This driver is also
+  available as a module ( = code which can be inserted in and removed
+  from the running kernel whenever you want). If you want to compile
+  it as a module, say M here and read Documentation/modules.txt.
+
+Frame Relay (DLCI) support
+CONFIG_DLCI
+  This is support for the frame relay protocol; frame relay is a fast
+  low-cost way to connect to a remote internet access provider or to
+  form a private wide area network. The one physical line from your
+  box to the local "switch" (i.e. the entry point to the frame relay
+  network, usually at the phone company) can carry several logical
+  point-to-point connections to other computers connected to the frame
+  relay network. For a general explanation of the protocol, check out
+  http://frame-relay.indiana.edu/4000/4000index.html on the WWW. (To
+  browse the WWW, you need to have access to a machine on the Internet
+  that has one of the programs lynx, netscape or Mosaic.) To use frame
+  relay, you need supporting hardware (FRAD) and certain programs from
+  the net-tools package as explained in
+  Documentation/networking/framerelay.txt. This driver is also
+  available as a module ( = code which can be inserted in and removed
+  from the running kernel whenever you want). If you want to compile
+  it as a module, say M here and read Documentation/modules.txt.
+
+Max open DLCI
+CONFIG_DLCI_COUNT 
+  This is the maximal number of logical point-to-point frame relay
+  connections (the identifiers of which are called DCLIs) that
+  the driver can handle. The default is probably fine.
+
+Max DLCI per device
+CONFIG_DLCI_MAX
+  You can specify here how many logical point-to-point frame relay
+  connections (the identifiers of which are called DCLIs) should be
+  handled by each of your hardware frame relay access devices. Go with
+  the default.
+
+Sangoma S502A FRAD support
+CONFIG_SDLA
+  Say Y here if you need a driver for the Sangoma S502A, S502E, and
+  S508 Frame Relay Access Devices. These are multi-protocol
+  cards, but only frame relay is supported by the driver at this
+  time. Please read Documentation/framerelay.txt. This driver is also
+  available as a module ( = code which can be inserted in and removed
+  from the running kernel whenever you want). If you want to compile
+  it as a module, say M here and read Documentation/modules.txt.
+
+Sun LANCE Ethernet support
+CONFIG_SUN_LANCE
+  This is support for lance ethernet cards on Sun workstations such as
+  the Sparcstation IPC (any Sparc with a network interface 'le0' under
+  SunOS basically).
+
+Sun Intel Ethernet support
+CONFIG_SUN_INTEL
+  This is support for the intel ethernet cards on some Sun workstations
+  (all those with a network interface 'ie0' under SunOS).
+
+Western Digital/SMC cards
+CONFIG_NET_VENDOR_SMC
+  If you have a network (ethernet) card belonging to this class, say Y
+  and read the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. If you plan to use more than
+  one network card under linux, read the Multiple-Ethernet-mini-HOWTO,
+  available from sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini. Note that
+  the answer to this question doesn't directly affect the kernel:
+  saying N will just cause this configure script to skip all the
+  questions about Western Digital cards. If you say Y, you will be
+  asked for your specific card in the following questions. If you plan
+  to use more than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+WD80*3 support
+CONFIG_WD80x3
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+SMC Ultra support
+CONFIG_ULTRA
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  This driver is also
+  available as a module ( = code which can be inserted in and removed
+  from the running kernel whenever you want). If you want to compile
+  it as a module, say M here and read Documentation/modules.txt as
+  well as Documentation/networking/net-modules.txt. If you plan to use
+  more than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+  Important: There have been many reports that, with some motherboards
+  mixing an SMC Ultra and an Adaptec AHA1542 SCSI card causes corruption
+  problems with many operating systems.
+
+SMC 9194 Support
+CONFIG_SMC9194
+  This is support for the SMC9xxx based Ethernet cards.  Choose this
+  option if you have a DELL laptop with the docking station, or
+  another SMC9192/9194 based chipset.  Say Y if you want it compiled
+  into the kernel, and read the the file drivers/net/README.smc9 and
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  This driver is also
+  available as a module ( = code which can be inserted in and removed
+  from the running kernel whenever you want). If you want to compile
+  it as a module, say M here and read Documentation/modules.txt as
+  well as Documentation/networking/net-modules.txt. If you plan to use
+  more than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+AMD LANCE and PCnet (AT1500 and NE2100) support
+CONFIG_LANCE
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. If you plan to use more than
+  one network card under linux, read the Multiple-Ethernet-mini-HOWTO,
+  available from sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+3COM cards
+CONFIG_NET_VENDOR_3COM
+  If you have a network (ethernet) card belonging to this class, say Y
+  and read the Ethernet-HOWTO, available via ftp (user: anonymous)
+  in sunsite.unc.edu:/pub/Linux/docs/HOWTO. Note that the answer to
+  this question doesn't directly affect the kernel: saying N will just
+  cause this configure script to skip all the questions about 3COM
+  cards. If you say Y, you will be asked for your specific card in the
+  following questions. If you plan to use more than one network card
+  under linux, read the Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini. 
+
+3c501 support
+CONFIG_EL1
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  Also, consider buying a new
+  card, since the 3c501 is slow and obsolete. This driver is also 
+  available as a module ( = code which can be inserted in and removed
+  from the running kernel whenever you want). If you want to compile
+  it as a module, say M here and read Documentation/modules.txt as well
+  as Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the 
+  Multiple-Ethernet-mini-HOWTO, available from 
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini - and don't use 3c501s.
+
+3c503 support
+CONFIG_EL2
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+3c505 support
+CONFIG_ELPLUS
+  Information about this network (ethernet) card can be found in
+  Documentation/networking/3c505.txt. If you have a card of this type,
+  say Y and read the Ethernet-HOWTO, available via ftp (user:
+  anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If you want to
+  compile this 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 as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+3c507 support
+CONFIG_EL16
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+3c509/3c579 support
+CONFIG_EL3
+  If you have a network (ethernet) card belonging to the 3Com
+  EtherLinkIII series, say Y and read the Ethernet-HOWTO, available
+  via ftp (user: anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO.
+  If you want to compile this 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 as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini. If your card is not
+  working you may need to use the DOS setup disk to disable Plug &
+  Play mode, and to select the default media type.
+
+3c590 series (592/595/597) "Vortex" support
+CONFIG_VORTEX
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. More specific information is
+  in Documentation/networking/vortex.txt and in the comments at the
+  beginning of drivers/net/3c59x.c. If you want to compile this
+  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 as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini
+
+Other ISA cards
+CONFIG_NET_ISA
+  If your network (ethernet) card hasn't been mentioned yet and its
+  bus system (that's the way the components of the card talk to each
+  other) is ISA (as opposed to EISA, VLB or PCI), say Y. Make sure you
+  know the name of your card. Read the Ethernet-HOWTO, available via
+  ftp (user: anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO. If
+  unsure, say Y.  Note that the answer to this question doesn't
+  directly affect the kernel: saying N will just cause this configure
+  script to skip all the remaining ISA network card questions.  If you
+  say Y, you will be asked for your specific card in the following
+  questions.  If you plan to use more than one network card under
+  linux, read the Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+ARCnet support
+CONFIG_ARCNET
+  If you have a network card of this type, say Y and check out the
+  (arguably) beautiful poetry in Documentation/networking/arcnet.txt. 
+  You might also want to have a look at the Ethernet-HOWTO, available
+  via ftp (user: anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO
+  (even though ARCnet is not really ethernet). This driver is also
+  available as a module ( = code which can be inserted in and removed
+  from the running kernel whenever you want). If you want to compile it
+  as a module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+  
+Enable arc0e (ARCnet "ether-encap" packet format)
+CONFIG_ARCNET_ETH
+  This allows you to use "ethernet encapsulation" with your ARCnet card
+  via the virtual arc0e device.  You only need arc0e if you want to
+  talk to nonstandard ARCnet software, specifically, DOS/Windows-style
+  "NDIS" drivers.  You do not need to enable this option to communicate
+  with industry-standard RFC1201 implementations, like the arcether.com
+  packet driver or most DOS/Windows ODI drivers.  RFC1201 is included
+  automatically as the arc0 device.  Please read the ARCnet
+  documentation in Documentation/networking/arcnet.txt for more
+  information about using arc0e and arc0s.
+
+Enable arc0s (ARCnet RFC1051 packet format)
+CONFIG_ARCNET_1051
+  This allows you to use RFC1051 with your ARCnet card via the virtual
+  arc0s device.  You only need arc0s if you want to talk to ARCnet
+  software complying with the "old" standard, specifically, the DOS
+  arcnet.com packet driver, Amigas running AmiTCP, and some variants of
+  NetBSD.  You do not need to enable this option to communicate with
+  industry-standard RFC1201 implementations, like the arcether.com
+  packet driver or most DOS/Windows ODI drivers.  RFC1201 is included
+  automatically as the arc0 device.  Please read the ARCnet
+  documentation in Documentation/networking/arcnet.txt for more
+  information about using arc0e and arc0s.
+
+Cabletron E21xx support
+CONFIG_E2100
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+DEPCA support
+CONFIG_DEPCA
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO as well as
+  drivers/net/depca.c.  If you want to compile this 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 as
+  well as Documentation/networking/net-modules.txt. If you plan to use
+  more than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+EtherWorks 3 support
+CONFIG_EWRK3
+  This driver supports the DE203, DE204 and DE205 network (ethernet)
+  cards. If this is for you, say Y and read drivers/net/README.ewrk3
+  in the kernel source as well as the Ethernet-HOWTO, available via
+  ftp (user: anonymous) from sunsite.unc.edu:/pub/Linux/docs/HOWTO.
+  If you want to compile this 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 as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+SEEQ8005 support
+CONFIG_SEEQ8005
+  This is a driver for the SEEQ 8005 network (ethernet) card. If this
+  is for you, read the Ethernet-HOWTO, available via ftp (user:
+  anonymous) from sunsite.unc.edu:/pub/Linux/docs/HOWTO. If you plan
+  to use more than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+AT1700 support
+CONFIG_AT1700
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+FMV-181/182/183/184 support
+CONFIG_FMV18X
+  If you have a Fujitsu FMV-181/182/183/184 network (ethernet) card,
+  say Y and read the Ethernet-HOWTO, available via ftp (user: anonymous)
+  in sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also
+  available as a module ( = code which can be inserted in and removed
+  from the running kernel whenever you want). If you want to compile it
+  as a module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini. If you use FMV-183 or
+  FMV-184 and it is not working, you may need to disable Plug & Play
+  mode of the card.
+
+EtherExpressPro support
+CONFIG_EEXPRESS_PRO
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+EtherExpress support
+CONFIG_EEXPRESS
+  If you have an EtherExpress16 network (ethernet) card, say Y and
+  read the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. Note that the Intel
+  EtherExpress16 card used to be regarded as a very poor choice
+  because the driver was very unreliable. We now have a new driver
+  that should do better. If you want 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 as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+NI5210 support
+CONFIG_NI52
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. If you plan to use more than
+  one network card under linux, read the Multiple-Ethernet-mini-HOWTO,
+  available from sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+NI6510 support
+CONFIG_NI65
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. If you plan to use more than
+  one network card under linux, read the Multiple-Ethernet-mini-HOWTO,
+  available from sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+Ottawa PI and PI/2 support
+CONFIG_PI
+  This is a driver for the Ottawa Amateur Radio Club PI and PI2 cards,
+  which are commonly used to send internet traffic over amateur radio. 
+  More information about these cards is on the WWW at
+  http://hydra.carleton.ca/info/pi2.html (To browse the WWW, you need
+  to have access to a machine on the Internet that has one of the
+  programs lynx, netscape or Mosaic). If you have one of these cards,
+  you can say Y here and should read the HAM-HOWTO, available via ftp
+  (user: anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO. Also,
+  you should have said Y to "AX.25 support" above, because AX.25 is
+  the protocol used for digital traffic over radio links.
+
+Gracilis PackeTwin support
+CONFIG_PT
+  This card is similar to the PI card (mentioned above).  It is used
+  mainly by amateur radio operators for packet radio.  You should have
+  already said Y to "AX.25 support" as this card uses that protocol.
+  More information about this driver can be found in the file
+  drivers/net/README.pt.  NOTE: The card is capable of DMA and full
+  duplex but neither of these have been coded in the driver as yet.
+
+WaveLAN support
+CONFIG_WAVELAN
+  These are cards for wireless ethernet-like networking. Supported are
+  AT&T GIS and NCR WaveLAN cards. If you want to use a card of this
+  type under Linux, say Y and read the Ethernet-HOWTO, available via
+  ftp (user: anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO. Some
+  more specific information is contained in
+  drivers/net/README.wavelan. This driver is also available as a
+  module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+HP PCLAN+ (27247B and 27252A) support
+CONFIG_HPLAN_PLUS
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+HP PCLAN (27245 and other 27xxx series) support
+CONFIG_HPLAN
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+HP 10/100VG PCLAN (ISA, EISA, PCI) support
+CONFIG_HP100
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If you want to compile this
+  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 as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+NE2000/NE1000 support
+CONFIG_NE2000
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+SK_G16 support
+CONFIG_SK_G16
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. If you plan to use more than
+  one network card under linux, read the Multiple-Ethernet-mini-HOWTO,
+  available from sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+EISA, VLB, PCI and on board controllers
+CONFIG_NET_EISA
+  This is another class of network cards which attach directly to the
+  bus. If you have one of those, say Y and read the Ethernet-HOWTO,
+  available via ftp (user: anonymous) from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO; if you are unsure, say
+  Y. Note that the answer to this question doesn't directly affect the
+  kernel: saying N will just cause this configure script to skip all
+  the questions about this class of network cards. If you say Y, you
+  will be asked for your specific card in the following questions.  If
+  you plan to use more than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+Ansel Communications EISA 3200 support
+CONFIG_AC3200
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+Apricot Xen-II on board ethernet
+CONFIG_APRICOT
+  If you have a network (ethernet) controller of this type, say Y and
+  read the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If you want to compile this
+  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 as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+DE425, DE434, DE435 support
+CONFIG_DE4X5
+  This is support for the DIGITAL series of PCI/EISA ethernet
+  cards. These include the DE425, DE434, DE435, DE450 and DE500
+  models. If you have a network card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  More specific information is
+  contained in drivers/net/README.de4x5. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+DECchip Tulip (dc21x4x) PCI support
+CONFIG_DEC_ELCP
+  This driver is developed for the SMC EtherPower series ethernet
+  cards and also works with cards based on the DECchip
+  21040/21041/21140 (Tulip series) chips. (If your card is NOT SMC
+  EtherPower 10/100 PCI (smc9332dst), you can also try the driver from
+  "DE425, DE434, DE435 support", above.) However, most people with a
+  network card of this type will say Y here. Do read the
+  Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. More specific information is
+  contained in Documentation/networking/tulip.txt. This driver is also
+  available as a module ( = code which can be inserted in and removed
+  from the running kernel whenever you want).  If you want to compile
+  it as a module, say M here and read Documentation/modules.txt as
+  well as Documentation/networking/net-modules.txt.
+
+Digi Intl. RightSwitch support
+CONFIG_DGRS
+  This is support for the Digi International RightSwitch series of
+  PCI/EISA ethernet switch cards.  These include the SE-4 and the SE-6
+  models. If you have a network card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  More specific information is
+  contained in drivers/net/README.dgrs. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+ICL EtherTeam 16i/32 support
+CONFIG_ETH16I
+  If you have a network (ethernet) card of this type, say Y and read
+  the Ethernet-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO. This driver is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. If you plan to use more
+  than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+Zenith Z-Note support
+CONFIG_ZNET
+  The Zenith Z-Note notebook computer has a built-in network
+  (ethernet) card, and this is the Linux driver for it. Note that the
+  IBM Thinkpad 300 is compatible with the Z-Note and is also supported
+  by this driver. Read the Ethernet-HOWTO, available via ftp (user:
+  anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO.
+
+Pocket and portable adaptors
+CONFIG_NET_POCKET
+  Cute little network (ethernet) devices which attach to the parallel
+  port ("pocket adaptors"), commonly used with laptops. If you have
+  one of those, say Y and read the Ethernet-HOWTO, available via ftp
+  (user: anonymous) from sunsite.unc.edu:/pub/Linux/docs/HOWTO. If you
+  want to plug a network card into the PCMCIA slot of your laptop
+  instead (PCMCIA is the standard for credit card size extension cards
+  used by all modern laptops), look in
+  cb-iris.stanford.edu:/pub/pcmcia and say N here.  Note that the
+  answer to this question doesn't directly affect the kernel: saying N
+  will just cause this configure script to skip all the questions
+  about this class of network devices.  If you say Y, you will be
+  asked for your specific device in the following questions.  If you
+  plan to use more than one network device under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini. If you intend to use an
+  adaptor attaching to the parallel port as well as a parallel
+  printer, you should compile both drivers as modules (if possible).
+
+AT-LAN-TEC/RealTek pocket adaptor support
+CONFIG_ATP
+  This is a network (ethernet) device which attaches to your parallel
+  port. Read drivers/net/atp.c as well as the Ethernet-HOWTO,
+  available via ftp (user: anonymous) from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO if you want to use this. If
+  you plan to use more than one network card under linux, read the
+  Multiple-Ethernet-mini-HOWTO, available from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini. If you intend to use
+  this driver, you should have said N to the Parallel Printer support,
+  because the two drivers don't like each other.
+
+D-Link DE600 pocket adaptor support
+CONFIG_DE600
+  This is a network (ethernet) device which attaches to your parallel
+  port. Read drivers/net/README.DLINK as well as the Ethernet-HOWTO,
+  available via ftp (user: anonymous) from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO if you want to use this.  If
+  you want to compile this 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. If you intend to use this
+  pocket adaptor as well as a parallel printer, you should compile
+  both drivers as modules. If you plan to use more than one network
+  card under linux, read the Multiple-Ethernet-mini-HOWTO, available
+  from sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+
+D-Link DE620 pocket adaptor support
+CONFIG_DE620
+  This is a network (ethernet) device which attaches to your parallel
+  port. Read drivers/net/README.DLINK as well as the Ethernet-HOWTO,
+  available via ftp (user: anonymous) from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO if you want to use this.  If
+  you want to compile this 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. If you intend to use this
+  pocket adaptor as well as a parallel printer, you should compile
+  both drivers as modules. If you plan to use more than one network
+  card under linux, read the Multiple-Ethernet-mini-HOWTO, available
+  from sunsite.unc.edu:/pub/Linux/docs/HOWTO/mini.
+ 
+Token Ring driver support
+CONFIG_TR
+  Token Ring is IBM's way of communication on a local network; the
+  rest of the world uses ethernet. If you are connected to a token
+  ring network and want to use your Token Ring card under Linux, say Y.
+  Most people can say N here.
+
+IBM Tropic chipset based adaptor support
+CONFIG_IBMTR
+  This is support for all IBM Token Ring cards that don't use DMA. If
+  you have such a beast, say Y, otherwise N. Warning: this driver will
+  almost definitely fail if more than one active Token Ring card is
+  present. This driver is also available as a module ( = code which
+  can be inserted in and removed from the running kernel whenever you
+  want). If you want to compile it as a module, say M here and read
+  Documentation/modules.txt.
+
+Support non-SCSI/IDE/ATAPI drives
+CONFIG_CD_NO_IDESCSI
+  If you have a CDROM drive that is neither SCSI nor IDE/ATAPI, say Y
+  here, otherwise N. Read the CDROM-HOWTO, available via ftp (user:
+  anonymous) from sunsite.unc.edu:/pub/Linux/docs/HOWTO. Note that the
+  answer to this question doesn't directly affect the kernel: saying N
+  will just cause this configure script to skip all the questions
+  about these CDROM drives. If you are unsure what you have, say Y and
+  find out whether you have one of the following drives.
+  For each of these drivers, a file Documentation/cdrom/<driver_name>
+  exists. Especially in cases where you do not know exactly which kind
+  of drive you have you should read there.
+  Most of these drivers use a file include/linux/<driver_name>.h where
+  you can define your interface parameters and switch some internal
+  goodies.
+  All these CDROM drivers are also usable as a module (= code which can
+  be inserted in and removed from the running kernel whenever you want).
+  If you want to compile them as module, say M instead of Y and read
+  Documentation/modules.txt.
+  If you want to use any of these CDROM drivers, you also have to say
+  Y to "ISO9660 cdrom filesystem support" below (this answer will get
+  "defaulted" for you if you enable any of the Linux CDROM drivers).
+
+Sony CDU31A/CDU33A CDROM support
+CONFIG_CDU31A
+  These CDROM drives have a spring-pop-out caddyless drawer, and a
+  rectangular green LED centered beneath it.  NOTE: these CDROM drives
+  will not be auto detected by the kernel at boot time; you have to
+  provide the interface address as an option to the kernel at boot
+  time as described in Documentation/cdrom/cdu31a or fill in your
+  parameters into linux/drivers/cdrom/cdu31a.c. See the documentation
+  of your boot loader (lilo or loadlin) about how to pass options to
+  the kernel. The lilo procedure is also explained in the SCSI-HOWTO.
+
+Standard Mitsumi [no XA/Multisession] CDROM support
+CONFIG_MCD
+  This is the older of the two drivers for the older Mitsumi models
+  LU-005, FX-001 and FX-001D. This is not the right driver for the 
+  FX-001DE and the triple or quad speed models (all these are IDE/ATAPI
+  models).
+  With the old LU-005 model, the whole drive chassis slides out for
+  cd insertion.  The FX-xxx models use a motorized tray type mechanism.
+  Note that this driver does not support XA or MultiSession CDs (PhotoCDs).
+  There is a new driver (next question) which can do this. If you want
+  that one, say N here.
+  If the driver doesn't work out of the box, you might want to have
+  a look at linux/include/linux/mcd.h.
+
+Mitsumi [XA/MultiSession] support
+CONFIG_MCDX
+  Use this driver if you want to be able to read XA or MultiSession
+  CDs (PhotoCDs) as well as ordinary CDs with your Mitsumi LU-005,
+  FX-001 or FX-001D CDROM drive. In addition, this driver uses much less
+  kernel memory than the old one, if that is a concern. This driver is
+  able to support more than one drive, but each drive needs a separate
+  interface card. Check out Documentation/cdrom/mcdx.
+
+Matsushita/Panasonic/Creative, Longshine, TEAC CDROM support
+CONFIG_SBPCD
+  This driver supports most of the drives which use the Panasonic or
+  SoundBlaster interface.
+  The Matsushita CR-521, CR-522, CR-523, CR-562, CR-563 drives
+  (sometimes labeled "Creative"), the CreativeLabs CD200, the
+  Longshine LCS-7260, the "IBM External ISA CDROM" (in fact a CR-56x
+  model), the TEAC CD-55A fall under this category. Some other
+  "electrically compatible" drives (Vertos, Genoa, some Funai models)
+  are currently not supported; for the Sanyo H94A drive currently a
+  separate driver (asked later) is responsible.  Most drives have a
+  uniquely shaped faceplate, with a caddyless motorized drawer, but
+  without external brand markings. The older CR-52x drives have a
+  caddy and manual loading/eject, but still no external markings.  The
+  driver is able to do an extended auto-probing for interface
+  addresses and drive types; this can help to find facts in cases you
+  are not sure, but can consume some time during the boot process if
+  none of the supported drives gets found.
+  Once your drive got found, you should enter the reported parameters 
+  into linux/include/linux/sbpcd.h and set "DISTRIBUTION 0" there.
+  This driver can support up to four CDROM interface cards, and each
+  card can support up to four CDROM drives; if you say Y here, you
+  will be asked how many controllers you have. If compiled as a
+  module, only one interface card (but with up to four drives) is
+  usable.
+
+Matsushita/Panasonic, ... second CDROM controller support
+CONFIG_SBPCD2
+  Say Y here only if you have two CDROM controller boards of this type
+  (usually only if you have more than four drives). You should enter
+  the parameters for the second, third and fourth interface card into
+  linux/include/linux/sbpcd.h before compiling the new kernel.
+
+Aztech/Orchid/Okano/Wearnes/TXC/CyDROM  CDROM support
+CONFIG_AZTCD
+  This is your driver if you have an Aztech CDA268-01A, Orchid
+  CD-3110, Okano or Wearnes CDD110, Conrad TXC, or CyCDROM CR520 or
+  CR540 CDROM drive.  This driver - just like all these CDROM drivers
+  - is NOT for CDROM drives with IDE/ATAPI interface, such as Aztech
+  CDA269-031SE.
+
+Sony CDU535 CDROM support
+CONFIG_CDU535
+  This is the driver for the older Sony CDU-535 and CDU-531 CDROM drives.
+
+Goldstar R420 CDROM support
+CONFIG_GSCD
+  If this is your CDROM drive, say Y here.
+  As described in linux/Documentation/cdrom/gscd, you might have to
+  change a setting in the file include/linux/gscd.h before compiling
+  the kernel.
+
+Philips/LMS CM206 CDROM support
+CONFIG_CM206
+  If you have a Philips/LMS CDROM drive cm206 in combination with a
+  cm260 host adapter card, say Y here.
+
+Optics Storage DOLPHIN 8000AT CDROM support
+CONFIG_OPTCD
+  This is the driver for the 'DOLPHIN' drive with a 34-pin Sony
+  compatible interface. It also works with the Lasermate CR328A. If
+  you have one of those, say Y. This driver does not work for the
+  Optics Storage 8001 drive; use the IDE-ATAPI CDROM driver for that
+  one. 
+
+Sanyo CDR-H94A CDROM support
+CONFIG_SJCD
+  If this is your CDROM drive, say Y here. Command line option
+  (or 'append=' option in /etc/lilo.conf) is:
+                sjcd=<port>
+  Here 'port' is the base i/o address used by the drive. It defaults
+  to port=0x340.
+
+Soft configurable cdrom interface card support
+CONFIG_CDI_INIT
+  If you want to include boot-time initialization of any cdrom
+  interface card that is software configurable, say Y here.
+  Currently only the ISP16/MAD16/Mozart cards are supported.
+
+ISP16/MAD16/Mozart soft configurable cdrom interface support
+CONFIG_ISP16_CDI
+  If you want any of these cdrom interface cards based on the
+  OPTi 82C928 or 82C929 chips get detected and possibly configured
+  at boot time, please say Y. Boot time command line options (or
+  'append=' options in /etc/lilo.conf) are:
+                isp16=<port>,<irq>,<dma>,<drive_type>
+  Here 'port','irq' and 'dma' are the base i/o address, irq number and
+  dma line assumed to be used by the attached cdrom
+  drive. 'drive_type' is the type of cdrom drive or its emulation
+  mode. Valid values for drive_type include: Sanyo, Panasonic (same as
+  Sanyo), Sony and Mitsumi.  Default values are: port=0x340, irq=0,
+  dma=0, drive_type=Sanyo.
+  The command line
+                isp16=noisp16
+  will skip detection and configuration after all.
+  N.B. options are case sensitive. 
+  Read Documentation/cdrom/isp16 for details. 
+
+Quota support
+CONFIG_QUOTA
+  If you say Y here, you will be able to set per user limits for disk
+  usage (also called diskquotas). Currently, it works only for the
+  ext2 filesystem. You need additional software in order to use quota
+  support; check the file Documentation/Changes for that. Probably the
+  quota support is only useful for multi user systems. If unsure, say
+  N.
+
+Mandatory lock support
+CONFIG_LOCK_MANDATORY
+  File locking is a system designed to prevent that several processes
+  write to the same file at the same time, causing data
+  corruption. Mandatory file locking is more secure than the usual
+  algorithm and is used by some Unix System 5 style database
+  applications. For details, read Documentation/mandatory.txt. To use
+  this option safely you must have newer NFS daemons, new samba, new
+  netatalk, new mars-nwe and other file servers. At the time of
+  writing none of these are available. So it's safest to say N here
+  unless you really know that you need this feature.
+
+Minix fs support
+CONFIG_MINIX_FS
+  Minix is a simple operating system used in many classes about
+  OS's. The minix filesystem (= method to organize files on a harddisk
+  partition or a floppy disk) was the original filesystem for Linux,
+  has been superseded by the second extended filesystem ext2fs but is
+  still used for root/boot and other floppies or ram disks since it is
+  leaner. You don't want to use it on your harddisk because of certain
+  built-in restrictions. This option will enlarge your kernel by about
+  25 kB. Everyone should say Y or M so that they are able to read this
+  common floppy format.  If you want to compile this 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. Note that the filesystem of your root
+  partition cannot be compiled as a module.
+
+Extended fs support
+CONFIG_EXT_FS
+  This is the old Linux filesystem (= method to organize files on a
+  harddisk partition or a floppy disk) and not in use anymore. It
+  enlarges your kernel by about 25 kB. Let's all kill this beast. Say
+  N.
+
+Second extended fs support
+CONFIG_EXT2_FS
+  This is the de facto standard Linux filesystem (= method to organize
+  files on a storage device) for harddisks. You want to say Y, unless
+  you intend to use Linux exclusively from inside a DOS partition
+  using the umsdos filesystem. The advantage of the latter is that you
+  can get away without repartitioning your hard drive (which often
+  implies backing everything up and restoring afterwards); the
+  disadvantage is that Linux becomes susceptible to DOS viruses and
+  that umsdos is somewhat slower than ext2fs. Even if you want to run
+  Linux in this fashion, it might be a good idea to have ext2fs
+  around: it enables you to read more floppy disks and facilitates the
+  transition to a *real* Linux partition later. Another (rare) case
+  which doesn't require ext2fs is a diskless Linux box which mounts
+  all files over the network using NFS (in this case it's sufficient
+  to enable NFS filesystem support below; if you are planning to do
+  this, have a look at the netboot package in
+  /pub/Linux/system/Linux-boot/, available via ftp (user: anonymous)
+  from sunsite.unc.edu, extract with "tar xzvf filename"). There is a
+  short ext2fs-FAQ, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/faqs. This option will enlarge your
+  kernel by about 41 kB. Default is Y.
+
+xiafs filesystem support
+CONFIG_XIA_FS
+  This is an old filesystem (= method to organize files on a harddisk
+  partition or a floppy disk) and not in use anymore. This option
+  would enlarge your kernel by about 28 kB. Let's all kill this beast:
+  say N.  If you want to compile this 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. Note that the
+  filesystem of your root partition cannot be compiled as a module.
+
+fat fs support
+CONFIG_FAT_FS
+  If you want to use one of the FAT-based filesystems (the MS-DOS,
+  VFAT (Windows'95) and UMSDOS filesystems), then you must include
+  FAT support. This is not a filesystem in itself, but it provides
+  the foundation for the other filesystems. This option will enlarge
+  your kernel about 24 kB. If unsure, say Y. If you want to compile
+  this as a module however ( = code which can be inserted in and 
+  removed from the running kernel whenever you want), say M here and
+  read Documentation/modules.txt. Note that if you compile the FAT
+  support as a module, you cannot compile any of the FAT-based file-
+  systems into the kernel - they will have to be modules as well.
+  The filesystem of your root partition cannot be a module.
+
+msdos fs support
+CONFIG_MSDOS_FS
+  This allows you to mount MSDOS partitions of your harddrive (unless
+  they are compressed; to access compressed MSDOS partitions under
+  Linux, you can either use the DOS emulator DOSEMU, described in the
+  DOSEMU-HOWTO, available via ftp (user: anonymous) at
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO, or try dmsdosfs in
+  sunsite.unc.edu:/pub/Linux/system/Filesystems/dosfs. If you intend
+  to use dosemu with a non-compressed MSDOS partition, say Y here) and
+  MSDOS floppies. This means that file access becomes transparent,
+  i.e. the MSDOS files look and behave just like all other Unix files.
+  Another way to read and write MSDOS floppies from within Linux (but
+  not transparently) is with the mtools ("man mtools") program suite,
+  which doesn't require the msdos filesystem support.  If you want to
+  use umsdos, the Unix-like filesystem on top of DOS, which allows you
+  to run Linux from within a DOS partition without repartitioning,
+  you'll have to say Y or M here. If your have Windows'95 or Windows
+  NT installed on your MSDOS partitions, you should use the VFAT
+  filesystem instead, or you will not be able to see the long
+  filenames generated by Windows'95 / Windows NT. This option will
+  enlarge your kernel by about 7 kB. If unsure, say Y. This will only
+  work if you said Y to "fat fs support" as well. If you want to
+  compile this as a module however ( = code which can be inserted in
+  and removed from the running kernel whenever you want), say M here
+  and read Documentation/modules.txt. Note that the filesystem of your
+  root partition cannot be a module.
+
+vfat fs support
+CONFIG_VFAT_FS
+  This allows you to mount MSDOS partitions of your harddrive. It
+  will let you use filenames in a way compatible with the long 
+  filenames used by Windows'95 and Windows NT fat-based (not NTFS)
+  partitions. It does not support Windows'95 compressed filesystems.
+  You cannot use the VFAT filesystem for your root partition; use
+  UMSDOS instead. This option enlarges your kernel by about 10 kB and
+  it only works if you enabled the "fat fs support" above. Please read
+  the file Documentation/filesystems/vfat.txt for details.
+  If unsure, say N. If you want to compile this 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.
+
+umsdos: Unix like fs on top of std MSDOS fs
+CONFIG_UMSDOS_FS
+  Say Y here if you want to run Linux from within an existing DOS
+  partition of your harddrive. The advantage of this is that you can
+  get away without repartitioning your hard drive (which often implies
+  backing everything up and restoring afterwards) and hence you're
+  able to quickly try out Linux or show it to your friends; the
+  disadvantage is that Linux becomes susceptible to DOS viruses and
+  that UMSDOS is somewhat slower than ext2fs.  Another use of umsdos
+  is to write files with long unix filenames to MSDOS floppies; it
+  also allows unix style softlinks and owner/permissions of files on
+  MSDOS floppies. You will need a program called umssync in order to
+  make use of umsdos. Read Documentation/filesystems/umsdos.txt. This
+  option enlarges your kernel by about 25 kB and it only works if you
+  enabled both "fat fs support" and "msdos fs support" above. If
+  unsure, say N.  If you want to compile this 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. Note that the filesystem of your root
+  partition cannot be a module.
+
+/proc filesystem support
+CONFIG_PROC_FS
+  This is a virtual filesystem providing information about the status
+  of the system. "Virtual" means that it doesn't take up any space on
+  your harddisk: the files are created on the fly when you access
+  them. Also, you cannot read the files with less: you need to use
+  more or cat. The filesystem is explained in the Kernel Hacker's
+  Guide, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/LDP and also on the proc(8) manpage
+  ("man 8 proc").  This option will enlarge your kernel by about 18
+  kB. It's totally cool; for example, "cat /proc/interrupts" gives
+  information about what the different IRQs are used for at the moment
+  (there is a small number of Interrupt ReQuest lines in your computer
+  that are used by the periphery to gain the CPU's attention - often a
+  source of trouble if two devices are mistakenly configured to use
+  the same IRQ). Several programs depend on this, so everyone should
+  say Y here.
+  
+NFS filesystem support
+CONFIG_NFS_FS
+  If you are connected to some other (usually local) Unix computer
+  (using SLIP, PLIP, PPP or ethernet) and want to mount files
+  residing on that computer (the NFS server) using the Network
+  File Sharing protocol, say Y. "Mounting files" means that the client
+  can access the files with usual UNIX commands as if they were
+  sitting on the client's harddisk. For this to work, the server must
+  run the programs nfsd and mountd (but does not need to have NFS
+  filesystem support enabled). NFS is explained in the Network
+  Administrator's Guide, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/LDP, and on its man page: "man
+  nfs". There is also a NFS-FAQ in
+  sunsite.unc.edu:/pub/Linux/docs/faqs which presumes that you know
+  the basics of NFS already. If you say Y here, you should have said Y
+  to TCP/IP networking also. This option would enlarge your kernel by
+  about 27 kB. This filesystem is also available as a module ( = code
+  which can be inserted in and removed from the running kernel
+  whenever you want). If you want to compile it as a module, say M
+  here and read Documentation/modules.txt. If you configure a diskless
+  machine which will mount its root filesystem over nfs, you cannot
+  compile this driver as a module. If you don't know what all this is
+  about, say N.
+
+Root file system on NFS
+CONFIG_ROOT_NFS
+  If you want your Linux box to mount its whole root filesystem from
+  some other computer over the net via NFS (presumably because your
+  box doesn't have a harddisk), say Y. Read Documentation/nfsroot.txt
+  for details. Most people say N here.
+
+BOOTP support
+CONFIG_RNFS_BOOTP
+  If you want your Linux box to mount its whole root filesystem from
+  some other computer over the net via NFS and you want the IP address
+  of your computer to be discovered automatically at boot time using
+  the BOOTP protocol (a special protocol designed for doing this job),
+  say Y here. In case the boot ROM of your network card was designed
+  for booting Linux and does BOOTP itself, providing all necessary
+  information on the kernel command line, you can say N here.  If
+  unsure, say Y. Note that in case you want to use BOOTP, a BOOTP
+  server must be operating on your network. Read
+  Documentation/nfsroot.txt for details.
+
+RARP support
+CONFIG_RNFS_RARP
+  If you want your Linux box to mount its whole root filesystem from
+  some other computer over the net via NFS and you want the IP address
+  of your computer to be discovered automatically at boot time using
+  the RARP protocol (an older protocol which is being obsoleted by
+  BOOTP), say Y here. Note that in case you want to use RARP, a RARP
+  server must be operating on your network. Read
+  Documentation/nfsroot.txt for details.
+
+ISO9660 cdrom filesystem support
+CONFIG_ISO9660_FS
+  This is the standard filesystem used on CDROMs. It was previously
+  known as "High Sierra Filesystem" and is called "hsfs" on other Unix
+  systems. The so-called Rock-Ridge extensions which allow for long
+  Unix filenames are also supported by this driver. If you have a
+  CDROM drive and want to do more with it than just listen to audio
+  CDs and watch its LEDs, say Y (and read the CDROM-HOWTO, available
+  via ftp (user: anonymous) from
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO), thereby enlarging your
+  kernel by about 27 kB; otherwise say N.  If you want to compile this
+  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.
+
+OS/2 HPFS filesystem support (read only)
+CONFIG_HPFS_FS
+  OS/2 is IBM's operating system for PC's, the same as Warp, and HPFS
+  is the filesystem used for organizing files on OS/2 harddisk
+  partitions. Say Y if you want to be able to read files from an OS/2
+  HPFS partition of your harddrive. OS/2 floppies however are in
+  regular MSDOS format, so you don't need this option in order to be
+  able to read them. Read Documentation/filesystems/hpfs.txt. This
+  filesystem is also available as a module ( = code which can be
+  inserted in and removed from the running kernel whenever you
+  want). If you want to compile it as a module, say M here and read
+  Documentation/modules.txt. If unsure, say N.
+  
+System V and Coherent filesystem support
+CONFIG_SYSV_FS
+  SCO, Xenix and Coherent are commercial Unix systems for intel
+  machines. Enabling this option would allow you to read and write to
+  and from their floppies and harddisk partitions. If you have a
+  floppy or harddisk partition like that, it is probable that they
+  contain binaries from those other Unix systems; in order to run
+  these binaries, you will want to install iBCS2 (iBCS2 [Intel Binary
+  Compatibility Standard] is a kernel module which lets you run SCO,
+  Xenix, Wyse, Unix Ware, Dell Unix and System V programs under Linux
+  and is often needed to run commercial software, most prominently
+  WordPerfect. It's in tsx-11.mit.edu:/pub/linux/BETA). If you only
+  intend to mount files from some other Unix over the network using
+  NFS, you don't need the System V filesystem support (but you need
+  nfs filesystem support obviously). Note that this option is
+  generally not needed for floppies, since a good portable way to
+  transport files and directories between unixes (and even other
+  operating systems) is given by the tar program ("man tar").  Note
+  also that this option has nothing whatsoever to do with the option
+  "System V IPC". Read about the System V filesystem in
+  Documentation/filesystems/sysv-fs.txt. This option will enlarge your
+  kernel by about 34 kB. If you want to compile this 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. If you haven't heard about all of this
+  before, it's safe to say N.
+
+BSD UFS filesystem support (read only)
+CONFIG_UFS_FS
+  BSD and derivate versions of Unix (such as SunOS, FreeBSD, NetBSD
+  and NeXTstep) use a filesystem called UFS. Some System V Unixes can
+  create and mount partitions and diskettes using this filesystem
+  as well. Enabling this option allows you to mount these partitions
+  and diskettes read-only. If you only intend to mount files from
+  some other Unix over the network using NFS, you don't need the
+  UFS filesystem support (but you need nfs filesystem support
+  obviously). Note that this option is generally not needed for
+  floppies, since a good portable way to transport files and
+  directories between unixes (and even other operating systems)
+  is given by the tar program ("man tar"). When accessing NeXTstep
+  files, you may need to convert them from the NeXT character set
+  to the Latin1 character set; use GNU recode for this purpose.
+  Say Y to build UFS support into your kernel. If you want to compile
+  this 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. If you haven't heard about all of this
+  before, it's safe to say N.
+
+BSD disklabel (FreeBSD partition tables) support
+CONFIG_BSD_DISKLABEL
+  FreeBSD uses its own partition scheme on your PC. It requires only
+  one entry in the primary partition table of your disk and manages it
+  similarly to DOS extended partitions, putting in its first sector a
+  new partition table in disklabel format. Enabling this option allows
+  you to read these disklabels and further mount FreeBSD partitions on
+  your Linux box if you also have configured BSD ufs filesystem
+  support. If you don't know what all this is about, say N.
+
+SMD disklabel (Sun partition tables) support
+CONFIG_SMD_DISKLABEL
+  Like most systems, SunOS uses its own partition table format,
+  incompatible with all others. Enabling this option allows you to read
+  these partition tables and further mount SunOS disks on your Linux
+  box if you also have configured BSD ufs filesystem support. This is
+  mainly used to carry data from a Sparc under SunOS to your Linux box
+  via a removable medium like magneto-optical or ZIP drives. If you
+  don't know what all this is about, say N.
+
+SMB filesystem support (to mount WfW shares etc..)
+CONFIG_SMB_FS
+  SMB (Server Message Buffer) is the protocol Windows for Workgroups
+  (WfW), Windows NT and Lan Manager use to talk to each other over an
+  ethernet. Enabling this allows you to mount their filesystems and
+  access them just like any other unix directory. For details, read
+  Documentation/filesystems/smbfs.txt.  Note: if you just want your
+  box to act as an SMB *server* and make files and printing services
+  available to Windows clients (which need to have a TCP/IP stack),
+  you don't need to enable this filesystem support; you can use the
+  program samba (available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/system/Network/samba) for that. General
+  information about how to connect Linux, Windows machines and Macs is
+  on the WWW at http://eats.com/linux_mac_win.html (to browse the WWW,
+  you need to have access to a machine on the Internet that has one of
+  the programs lynx, netscape or Mosaic).  If you want to compile the
+  SMB support 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. Most people say N, however.
+
+SMB Win95 bug work-around
+CONFIG_SMB_WIN95
+  If you want to connect to a share exported by Windows 95, you should
+  say Y here. The Windows 95 server contains a bug that makes listing
+  directories unreliable. This option slows down the listing of
+  directories. This makes the Windows 95 server a bit more stable.
+
+NCP filesystem support (to mount NetWare volumes)
+CONFIG_NCP_FS
+  NCP (NetWare Core Protocol) is a protocol that runs over IPX and is
+  used by Novel NetWare clients to talk to file servers. It is to IPX
+  what nfs is to tcp/ip, if that helps. Enabling this option allows
+  you to mount NetWare file server volumes and to access them just
+  like any other Unix directory. For details, please read the file
+  Documentation/filesystems/ncpfs.txt in the kernel source and the
+  IPX-HOWTO on sunsite.unc.edu:/pub/Linux/docs/howto.  If you want to
+  compile this 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.
+
+Amiga FFS filesystem support (EXPERIMENTAL)
+CONFIG_AFFS_FS
+  The Fast File System (FFS) is the common filesystem used on harddisks
+  by Amiga (tm) Systems since AmigaOS Version 1.3 (34.20). It's also
+  possible to mount diskfiles used by the Un*X Amiga Emulator by Bernd
+  Schmidt (http://www-users.informatik.rwth-aachen.de/~crux/uae.html)
+  If you want to do the latter, you will also need the loop device
+  support. Say Y if you want to be able to read and write files from
+  and to an Amiga FFS partition of your harddrive. Amiga floppies
+  however cannot be read with this driver due to an incompatibility of
+  the floppy controller used in an Amiga and the standard floppy
+  controller in PCs and workstations. Read
+  Documentation/filesystems/affs.txt. This filesystem is also available
+  as a module ( = code which can be inserted in and removed from the
+  running kernel whenever you want). If you want to compile it as a
+  module, say M here and read Documentation/modules.txt.
+  If unsure, say N.
+
+Standard/generic serial support
+CONFIG_SERIAL
+  This selects whether you want to include the driver for the standard
+  serial ports.  People who might say N here are those that are
+  setting up dedicated ethernet WWW/ftp servers, or users that have
+  one of the various bus mice instead of a serial mouse.  (Note that
+  the Cyclades and Stallion multi serial port drivers do not need this
+  driver built in for them to work. They are completely independent of
+  each other.)  If you want to compile this driver as a module, say M
+  here and read Documentation/modules.txt.  [WARNING: Do not compile
+  this driver as a module if you are using non-standard serial ports,
+  since the configuration information will be lost when kerneld
+  automatically unloads the driver.  This limitation may be lifted in
+  the future.]  Most people will say Y or M here, so that they can use
+  serial mice, modems and similar devices connecting to the standard
+  serial ports.
+
+Digiboard PC/Xx Support
+CONFIG_DIGI
+  This is a driver for the Digiboard PC/Xe, PC/Xi, and PC/Xeve cards
+  that give you many serial ports. You would need something like this
+  to connect more than two modems to your linux box, for instance in
+  order to become a BBS. If you have a card like that, say Y here and
+  read the file Documentation/digiboard.txt.
+
+SDL RISCom/8 card support
+CONFIG_RISCOM8
+  This is a driver for the SDL Communications RISCom/8 multiport card,
+  that give you many serial ports. You would need something like this
+  to connect more than two modems to your linux box, for instance in
+  order to become a BBS. If you have a card like that, say Y here and
+  read the file Documentation/riscom8.txt. Also it's possible to say
+  M here and compile this driver as kernel loadable module.
+
+Cyclades async mux support
+CONFIG_CYCLADES
+  This is a driver for a card that gives you many serial ports. You
+  would need something like this to connect more than two modems to
+  your linux box, for instance in order to become a BBS. If you want
+  to compile this 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. If you haven't heard about it, it's
+  safe to say N. (As of 1.3.9x kernels, this driver's minor numbers
+  start at 0 instead of 32.)
+
+Stallion multiport serial support 
+CONFIG_STALDRV
+  Stallion cards give you many serial ports. You would need something
+  like this to connect more than two modems to your linux box, for
+  instance in order to become a BBS. If you say Y here, you will be
+  asked for your specific card model in the next questions. Make sure
+  to read drivers/char/README.stallion in this case. If you have never
+  heard about all this, it's safe to say N.
+ 
+Stallion EasyIO or EC8/32 support 
+CONFIG_STALLION n
+  If you have an EasyIO or EasyConnection 8/32 multiport Stallion
+  card, then this is for you; say Y. Make sure to read
+  drivers/char/README.stallion. If you want to compile this 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.
+
+Stallion EC8/64, ONboard, Brumby support
+CONFIG_ISTALLION
+  If you have an EasyConnection 8/64, ONboard, Brumby or Stallion
+  serial multiport card, say Y here. Make sure to read
+  drivers/char/README.stallion. To compile it 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.
+
+Parallel printer support
+CONFIG_PRINTER
+  If you intend to attach a printer to the parallel port of your Linux
+  box (as opposed to using a serial printer; if the connector at the
+  printer has 9 or 25 holes ["female"], then it's serial), say Y. Also
+  read the Printing-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If you want to compile this
+  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. If you want to use both a parallel
+  printer and PLIP, there are two cases: 1) If the printer and the
+  PLIP cable are to use the same parallel port (presumably because you
+  have just one), it is best to compile both drivers as modules and
+  load and unload them as needed. 2) To use different parallel ports
+  for the printer and the PLIP cable, you can say Y to this printer
+  driver, specify the base address of the parallel port(s) to use for
+  the printer(s) with the "lp" kernel command line option. (See the
+  documentation of your boot loader (lilo or loadlin) about how to
+  pass options to the kernel at boot time. The lilo procedure is also
+  explained in the SCSI-HOWTO, available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.) The standard base addresses
+  as well as the syntax of the "lp" command line option can be found
+  in drivers/char/lp.c. You can then say Y to the PLIP driver or,
+  preferably, M in which case Documentation/networking/net-modules.txt
+  tells you how to specify the port and IRQ to be used by PLIP at
+  module load time.
+
+
+Mouse Support (not serial mice)
+CONFIG_MOUSE
+  This is for machines with a bus mouse or a PS/2 mouse as opposed to
+  a serial mouse. Most people have a regular serial MouseSystem or
+  Microsoft mouse (made by Logitech) that plugs into a COM port
+  (rectangular with 9 or 25 pins). These people say N here. If you
+  have something else, read the Busmouse-HOWTO, available via ftp
+  (user: anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO and say Y
+  here. If you have a laptop, you either have to check the
+  documentation or experiment a bit to find out whether the trackball
+  is a serial mouse or not; it's best to say Y here for you. Note that
+  the answer to this question won't directly affect the kernel: saying
+  N will just cause this configure script to skip all the questions
+  about non-serial mice.  If unsure, say Y.
+
+Logitech busmouse support
+CONFIG_BUSMOUSE
+  Logitech mouse connected to a proprietary interface card. It's
+  generally a round connector with 9 pins. Note that the newer mice
+  made by Logitech don't use the Logitech protocol anymore; for those,
+  you don't need this option. You want to read the Busmouse-HOWTO,
+  available via ftp (user: anonymous) in
+  sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If you want to compile this
+  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. If you are unsure, say N and read the
+  HOWTO nevertheless: it will tell you what you have. 
+
+PS/2 mouse (aka "auxiliary device") support
+CONFIG_PSMOUSE
+  The PS/2 mouse connects to a special mouse port that looks much like
+  the keyboard port (small circular connector with 6 pins). This way,
+  the mouse does not use any serial ports. This port can also be used
+  for other input devices like light pens, tablets, keypads. Compaq,
+  AST and IBM all use this as their mouse port on currently shipping
+  machines. The trackballs of some laptops are PS/2 mice also. In
+  particular, the C&T 82C710 mouse on TI Travelmates is a PS/2
+  mouse. Although PS/2 mice are not technically bus mice, they are
+  explained in detail in the Busmouse-HOWTO, available via ftp (user:
+  anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If you want to
+  compile this 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. If you are unsure, say N and read
+  the HOWTO nevertheless: it will tell you what you have.
+
+C&T 82C710 mouse port support (as on TI Travelmate)
+CONFIG_82C710_MOUSE
+  This is a certain kind of PS/2 mouse used on the TI Travelmate. If
+  you are unsure, try first to say N here and come back if the mouse
+  doesn't work. Read the Busmouse-HOWTO, available via ftp (user:
+  anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO.
+
+Microsoft busmouse support
+CONFIG_MS_BUSMOUSE
+  These animals (also called Inport mice) are connected to an
+  expansion board using a round connector with 9 pins. If this is what
+  you have, say Y and read the Busmouse-HOWTO, available via ftp
+  (user: anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If you
+  want to compile this 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. If you are unsure, say N and
+  read the HOWTO nevertheless: it will tell you what you have. Also be
+  aware that several vendors talk about 'Microsoft busmouse' and
+  actually mean PS/2 busmouse - so count the pins on the connector.
+
+ATIXL busmouse support
+CONFIG_ATIXL_BUSMOUSE
+  This is a rare type of busmouse that is connected to the back of an
+  ATI video card. Note that most ATI mice are actually Microsoft
+  busmice. Read the Busmouse-HOWTO, available via ftp (user:
+  anonymous) in sunsite.unc.edu:/pub/Linux/docs/HOWTO.  If you want to
+  compile this 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. If you are unsure, say N and read
+  the HOWTO nevertheless: it will tell you what you have. 
+
+Support for user miscellaneous modules
+CONFIG_UMISC
+  This option forces generic miscellaneous minor device support in the
+  kernel, and allows later loading of user miscellaneous device
+  modules, such as drivers for optic pens and touchscreens. Unless you
+  need such specific modules, or are willing to write/test one, just
+  say N.
+
+QIC-02 tape support
+CONFIG_QIC02_TAPE
+  If you have a non-SCSI tape drive like that, say Y.
+
+Do you want runtime configuration for QIC-02
+CONFIG_QIC02_DYNCONF
+  You can either configure this driver once and for all by editing a
+  header file, in which case you should say N, or you can fetch a
+  program via anonymous ftp which is able to configure this driver
+  during runtime. If you want this, say Y.
+
+Ftape (QIC-80/Travan) support
+CONFIG_FTAPE
+  If you have a tape drive that is connected to your floppy
+  controller, say Y here. Some tape drives (like the Iomega Ditto
+  3200) come with a high speed controller of its own.  These drives
+  (and their companion controller) is also supported. If you have a
+  special controller (such as the CMS FC-10, FC-20, Iomega Mach-II, or
+  Ditto Dash), you must configure it by editing the file
+  drivers/char/ftape/Makefile. If you want to use such a tape drive on
+  a PCI-bus based system, please read the file
+  drivers/char/ftape/README.PCI. This driver is also available as a
+  runtime loadable module ( = code which can be inserted in and
+  removed from the running kernel whenever you want). If you want to
+  compile it as a module, say M here and read
+  Documentation/modules.txt.
+
+Zilog serial support
+CONFIG_SUN_ZS
+  This driver does not exist at this point, so you might as well say
+  N.
+
+Advanced Power Management
+CONFIG_APM
+  APM is a BIOS specification for saving power using several different
+  techniques.  This is mostly useful for battery powered laptops with
+  APM compliant BIOSes.  Specifically, the time will be reset after a
+  USER RESUME operation, the /proc/apm device will provide battery
+  status information, and user-space programs will receive
+  notification of APM "events" (e.g., battery status change).  This
+  driver does not spin down disk drives (see hdparm(8) for that); and
+  it doesn't turn off VESA-compliant "green" monitors.  This driver
+  does not support the TI 4000M TravelMate and the ACER 486/DX4/75
+  because they don't have compliant BIOSes.  Many "green" desktop
+  machines also don't have compliant BIOSes, and this driver will
+  cause those machines to panic during the boot phase (typically,
+  these machines are using a data segment of 0040, which is reserved
+  for the Linux kernel). If you get random kernel OOPSes that don't
+  seem to be related to anything and you have a motherboard with APM
+  support, try disabling/enabling this option. Generally, if you don't
+  have a battery in your machine, there isn't much point in using this
+  driver.
+
+Ignore USER SUSPEND
+CONFIG_APM_IGNORE_USER_SUSPEND
+  This option will ignore USER SUSPEND requests.  On machines with a
+  compliant APM BIOS, you want to say N.  However, on the NEC Versa M
+  series notebooks, it is necessary to say Y because of a BIOS bug.
+
+Enable APM at boot time
+CONFIG_APM_DO_ENABLE
+  Enable APM features at boot time.  From page 36 of the APM BIOS
+  specification: "When disabled, the APM BIOS does not automatically
+  power manage devices, enter the Standby State, enter the Suspend State,
+  or take power saving steps in response to CPU Idle calls."  This driver
+  will make CPU Idle calls when Linux is idle (unless this feature is
+  turned off -- see below).  This should always save battery power, but
+  more complicated APM features will be dependent on your BIOS
+  implementation.  You may need to turn this option off if your computer
+  hangs at boot time when using APM support, or if it beeps continuously
+  instead of suspending.  Turn this off if you have a NEC UltraLite Versa
+  33/C or a Toshiba T400CDT.  This is off by default since most machines
+  do fine without this feature.
+
+Do CPU IDLE calls
+CONFIG_APM_CPU_IDLE
+  Enable calls to APM CPU Idle/CPU Busy inside the kernel's idle loop.
+  On some machines, this can activate improved power savings, such as a
+  slowed CPU clock rate, when the machine is idle.  These idle calls are
+  made after the idle loop has run for some length of time (e.g., 333
+  mS).  On some machines, this will cause a hang at boot time or whenever
+  the CPU becomes idle.  (On machines with more than one CPU, this option
+  does nothing.)
+
+Enable console blanking using APM
+CONFIG_APM_DISPLAY_BLANK
+  Enable console blanking using the APM.  Some laptops can use this to
+  turn off the LCD backlight when the VC screen blanker blanks the
+  screen.  Note that this is only used by the VC screen blanker, and
+  won't turn off the backlight when using X11 (this also doesn't have
+  anything to do with your VESA-compliant power-saving monitor).
+  Further, this option doesn't work for all laptops -- it might not turn
+  off your backlight at all, or it might print a lot of errors to the
+  console, especially if you are using gpm.
+
+Power off on shutdown 
+CONFIG_APM_POWER_OFF
+  This option will power off the computer after the Linux kernel is halted
+  (e.g., with the halt(8) command).  As with the other APM options, this
+  option may not work reliably with some APM BIOS implementations.
+
+Watchdog Timer Support 
+CONFIG_WATCHDOG
+  If you enable this option and create a character special file
+  /dev/watchdog with major number 10 and minor number 130 using mknod
+  ("man mknod"), you will get a watchdog, i.e.: subsequently opening
+  the file and failing to write to it for longer than 1 minute will
+  result in rebooting the machine. This could be useful for a
+  networked machine that needs to come back online as fast as possible
+  after a lock-up. There's a watchdog implementation entirely in
+  software (which can sometimes fail to reboot the machine) and a
+  driver for hardware watchdog boards, which are more robust and can
+  also keep track of the temperature inside your computer. For
+  details, read Documentation/watchdog.txt in the kernel source. If
+  unsure, say N. This driver is also available as a module ( = code
+  which can be inserted in and removed from the running kernel
+  whenever you want). If you want to compile it as a module, say M
+  here and read Documentation/modules.txt.
+
+Disable watchdog shutdown on close
+CONFIG_WATCHDOG_NOWAYOUT
+  The default watchdog behaviour is to stop the timer if the process
+  managing it closes the file /dev/watchdog. It's always remotely
+  possible that this process might get killed. If you enable this
+  option, the watchdog cannot be stopped once it has been started.
+
+WDT Watchdog timer
+CONFIG_WDT
+  If you have a WDT500P or WDT501P watchdog board, say Y here,
+  otherwise N. It is not possible to probe for this board, which means
+  that you have to set the IO port and IRQ it uses in the kernel
+  source at the top of drivers/char/wdt.c. If you want to compile this
+  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.
+
+WDT501 features
+CONFIG_WDT_501
+  Saying Y here and creating a character special file /dev/temperature
+  with major number 10 and minor number 131 ("man mknod") will give
+  you a thermometer inside your computer: reading from
+  /dev/temperature yields one byte, the temperature in degrees
+  Fahrenheit. This works only if you have a WDT501P watchdog board
+  installed.
+
+Fan Tachometer
+CONFIG_WDT_501_FAN
+  Enable the Fan Tachometer on the WDT501. Only do this if you have a fan
+  tachometer actually set up.
+
+Software Watchdog
+CONFIG_SOFT_WATCHDOG
+  A software monitoring watchdog. This will fail to reboot your system
+  from some situations that the hardware watchdog will recover
+  from. Equally it's a lot cheaper to install. This driver is also
+  available as a module ( = code which can be inserted in and removed
+  from the running kernel whenever you want). If you want to compile
+  it as a module, say M here and read Documentation/modules.txt.
+
+Berkshire Products PC Watchdog card
+CONFIG_PCWATCHDOG
+  This is the driver for the Berkshire Products PC Watchdog card.
+  This card simply watches your kernel to make sure it doesn't freeze,
+  and if it does, it resets your computer after a certain amount of
+  time.  This driver is like the WDT501 driver but for different
+  hardware. The PC watchdog cards can be ordered from
+  http://www.berkprod.com. Some example rc.local files are available
+  from ftp.bitgate.com. This driver is also available as a module ( =
+  code which can be inserted in and removed from the running kernel
+  whenever you want). If you want to compile it as a module, say M
+  here and read Documentation/modules.txt.  Most people will say N.
+
+Enhanced Real Time Clock Support
+CONFIG_RTC
+  If you enable this option and create a character special file
+  /dev/rtc with major number 10 and minor number 135 using mknod ("man
+  mknod"), you will get access to the real time clock built into your
+  computer. Every PC has such a clock built in. It can be used to
+  generate signals from as low as 1Hz up to 8192Hz, and can also be
+  used as a 24 hour alarm.  It reports status information via the file
+  /proc/rtc and its behaviour is set by various ioctls on
+  /dev/rtc. People running SMP (= multiprocessor) versions of Linux
+  should enable this option to read and set the RTC clock in a SMP
+  compatible fashion. If you think you have a use for such a device
+  (such as periodic data sampling), then say Y here, and go read the
+  file Documentation/rtc.txt for details.
+
+Sound card support
+CONFIG_SOUND
+  If you have a Sound Card in your Computer, i.e. if it can say more
+  than an occasional beep, say Y. Be sure to have all the information
+  about your sound card and its configuration down (I/O port,
+  interrupt and DMA channel), because you will be asked for it. You
+  want to read the Sound-HOWTO, available via ftp (user: anonymous)
+  from sunsite.unc.edu:/pub/Linux/docs/HOWTO. There is also some
+  information in various README files in drivers/sound.  If you want
+  to compile this 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. I'm told that even without a sound
+  card, you can make your computer say more than an occasional beep,
+  by programming the PC speaker. Kernel patches and programs to do
+  that are at
+  sunsite.unc.edu:/pub/Linux/kernel/patches/console/pcsndrv-X.X.tar.gz,
+  to be extracted with "tar xzvf filename".
+
+ProAudioSpectrum 16 support
+CONFIG_PAS
+  Answer Y only if you have a Pro Audio Spectrum 16, ProAudio Studio
+  16 or Logitech SoundMan 16.  Don't answer 'y' if you have some other
+  card made by Media Vision or Logitech since they are not PAS16
+  compatible.
+
+SoundBlaster (SB, SBPro, SB16, clones) support
+CONFIG_SB
+  Answer "y" if you have an original SoundBlaster card made by
+  Creative Labs or a 100% hardware compatible clone (like the
+  Thunderboard or SM Games). If your card was in the list of supported
+  cards look at the card specific instructions in the
+  drivers/sound/Readme.cards file before answering this question. For
+  an unknown card you may answer Y if the card claims to be
+  SoundBlaster compatible.
+
+Generic OPL2/OPL3 FM synthesizer support
+CONFIG_ADLIB
+  Answer Y if your card has a FM chip made by Yamaha (OPL2/OPL3/OPL4).
+  Answering Y is usually a safe and recommended choice, however some
+  cards may have software (TSR) FM emulation. Enabling FM support with
+  these cards may cause trouble (I don't currently know of any such
+  cards, however).
+
+Gravis Ultrasound support
+CONFIG_GUS
+  Enable this option for any type of Gravis Ultrasound card, including
+  the GUS or GUS MAX.
+
+MPU-401 support (NOT for SB16)
+CONFIG_MPU401
+  Be careful with this question. The MPU401 interface is supported by
+  all soundcards. However, some natively supported cards have their
+  own driver for MPU401. Enabling the MPU401 option with these cards
+  will cause a conflict. Also, enabling MPU401 on a system that
+  doesn't really have a MPU401 could cause some trouble. If your card
+  was in the list of supported cards, look at the card specific
+  instructions in the drivers/sound/Readme.cards file. It's safe to
+  answer Y if you have a true MPU401 MIDI interface card.
+
+6850 UART Midi support
+CONFIG_UART6850
+  This option enables support for MIDI interfaces based on the 6850
+  UART chip. This interface is rarely found on sound cards.  It's safe
+  to answer N to this question.
+
+PSS (ECHO-ADI2111) support
+CONFIG_PSS
+  Answer Y only if you have Orchid SW32, Cardinal DSP16 or some other
+  card based on the PSS chipset (AD1848 codec + ADSP-2115 DSP chip +
+  Echo ESC614 ASIC CHIP).
+
+16 bit sampling option of GUS (_NOT_ GUS MAX)
+CONFIG_GUS16
+  Answer Y if you have installed the 16 bit sampling daughtercard on
+  your GUS.  Answer N if you have a GUS MAX, since enabling this
+  option disables GUS MAX support.
+
+GUS MAX support
+CONFIG_GUSMAX
+  Answer Y only if you have a Gravis Ultrasound MAX.
+
+Microsoft Sound System support
+CONFIG_MSS
+  Again think carefully before answering Y to this question.  It's
+  safe to answer Y if you have the original Windows Sound System card
+  made by Microsoft or Aztech SG 16 Pro (or NX16 Pro).  Also you may
+  answer Y in case your card is NOT among these:
+     ATI Stereo F/X, AdLib, Audio Excell DSP16, Cardinal DSP16,
+     Ensoniq SoundScape (and compatibles made by Reveal and Spea),
+     Gravis Ultrasound, Gravis Ultrasound ACE, Gravis Ultrasound Max,
+     Gravis Ultrasound with 16 bit option, Logitech Sound Man 16,
+     Logitech SoundMan Games, Logitech SoundMan Wave, MAD16 Pro (OPTi
+     82C929), Media Vision Jazz16, MediaTriX AudioTriX Pro, Microsoft
+     Windows Sound System (MSS/WSS), Mozart (OAK OTI-601), Orchid
+     SW32, Personal Sound System (PSS), Pro Audio Spectrum 16, Pro
+     Audio Studio 16, Pro Sonic 16, Roland MPU-401 MIDI interface,
+     Sound Blaster 1.0, Sound Blaster 16, Sound Blaster 16ASP, Sound
+     Blaster 2.0, Sound Blaster AWE32, Sound Blaster Pro, TI TM4000M
+     notebook, ThunderBoard, Turtle Beach Tropez, Yamaha FM
+     synthesizers (OPL2, OPL3 and OPL4), 6850 UART MIDI Interface.
+  For cards having native support in VoxWare, consult the card
+  specific instructions in drivers/sound/Readme.cards. Some drivers
+  have their own MSS support and enabling this option will cause a
+  conflict.
+
+Ensoniq Soundscape support
+CONFIG_SSCAPE
+  Answer Y if you have a soundcard based on the Ensoniq SoundScape
+  chipset. Such cards are being manufactured at least by Ensoniq, Spea
+  and Reveal (Reveal makes also other cards).
+
+MediaTriX AudioTriX Pro support
+CONFIG_TRIX
+  Answer Y if you have the AudioTriX Pro sound card manufactured
+  by MediaTrix.
+
+Support for MAD16 and/or Mozart based cards
+CONFIG_MAD16
+  Answer Y if your card has a Mozart (OAK OTI-601) or MAD16
+  (OPTi 82C928 or 82C929) audio interface chip. These chips are
+  currently quite common so it's possible that many no-name cards
+  have one of them. In addition the MAD16 chip is used in some
+  cards made by known manufacturers such as Turtle Beach (Tropez),
+  Reveal (some models) and Diamond (latest ones).
+
+Support for Crystal CS4232 based (PnP) cards
+CONFIG_CS4232
+  Enable this if you have a card based on the Crystal CS4232 chip set.
+
+Support for Turtle Beach Wave Front (Maui, Tropez) synthesizers
+CONFIG_MAUI
+  Enable this option if you have a Turtle Beach Wave Front, Maui, or 
+  Tropez sound card.
+
+Support for Crystal CS4232 based (PnP) cards
+CONFIG_CS4232
+  Use this option to enable experimental support for cards that use
+  the Plug and Play protocol.
+
+/dev/dsp and /dev/audio support
+CONFIG_AUDIO
+  Answering N disables /dev/dsp and /dev/audio, the A/D and D/A
+  converter devices.  Answer N only if you know you will not need
+  the option.  They are usually required.  Answer Y.
+
+MIDI interface support
+CONFIG_MIDI
+  Answering N disables /dev/midixx devices and access to any MIDI
+  ports using /dev/sequencer and /dev/music. This option also affects
+  any MPU401 and/or General MIDI compatible devices.  Answer Y.
+
+FM synthesizer (YM3812/OPL-3) support
+CONFIG_YM3812
+  Answer Y here, unless you know you will not need the option.
+
+Sun Audio support
+CONFIG_SUN_AUDIO
+  This is support for the soundcards on Sun workstations. The code
+  does not exist yet, so you might as well say N here.
+
+Kernel profiling support
+CONFIG_PROFILE
+  This is for kernel hackers who want to know how much time the kernel
+  spends in the various procedures. The information is stored in
+  /proc/profile (enable the /proc filesystem!) and in order to read
+  it, you need the readprofile package from sunsite.unc.edu. Its
+  manpage gives information regarding the format of profiling data. To
+  become a kernel hacker, you can start with the Kernel Hacker's
+  Guide, available via ftp (user: anonymous) from
+  sunsite.unc.edu:/pub/Linux/docs/LDP. Mere mortals say N.
+ 
+Profile shift count
+CONFIG_PROFILE_SHIFT
+  This is used to adjust the granularity with which the addresses of
+  executed instructions get recorded in /proc/profile. But since you
+  enabled "Kernel profiling support", you must be a kernel hacker and
+  hence you know what this is about :-)
+
+ISDN subsystem
+CONFIG_ISDN
+  ISDN ("Integrated Services Digital Networks", called RNIS in
+  France) is a special type of fully digital telephone line; it's
+  mostly used to connect to your Internet service provider (with SLIP
+  or PPP). The main advantage is that the speed is higher than
+  ordinary modem/telephone connections. It only works if your computer
+  is equipped with an ISDN card and both you and your service provider
+  purchased an ISDN line from your phone company.  For details, read
+  http://alumni.caltech.edu/~dank/isdn/ on the WWW. (To browse the
+  WWW, you need to have access to a machine on the Internet that has
+  one of the programs lynx, netscape or Mosaic.)  This driver allows
+  you to use an ISDN-card for networking connections and as dialin/out
+  device. The isdn-tty's have a built in AT-compatible modem
+  emulator. Network devices support autodial, channel-bundling,
+  callback and caller-authentication without having a daemon
+  running. A reduced T.70 protocol is supported with tty's suitable
+  for German BTX. On D-Channel, the protocols EDSS1 and 1TR6 are
+  supported. See Documentation/isdn/README for more information.
+
+Support synchronous PPP
+CONFIG_ISDN_PPP
+  This enables synchronous PPP via ISDN. This protocol is used by
+  Cisco or Sun for example. So you want say Y here if the other end of
+  your ISDN connection supports it. You will need a special version of
+  pppd (called ipppd) for using this feature. See
+  Documentation/isdn/README.syncppp and Documentation/isdn/syncPPP.FAQ
+  for more information.
+
+Support generic MP (RFC 1717)
+CONFIG_ISDN_MPP
+  With synchronous PPP enabled, it is possible to increase throughput
+  by bundling several ISDN-connections, using this protocol. See
+  Documentation/isdn/README.syncppp for more information.
+
+Use VJ-compression with synchronous PPP
+CONFIG_ISDN_PPP_VJ
+  This enables Van Jacobson header compression for synchronous PPP.
+
+Support audio via ISDN
+CONFIG_ISDN_AUDIO
+  With this option enabled, the modem-emulator supports a subset
+  of the EIA Class 8 Voice commands. Using a getty with voice-support
+  (mgetty+sendfax by gert@greenie.muc.de with an extension, available
+  with the ISDN utility package for example), you will be able
+  to use your Linux box as an ISDN-answering machine. Of course, this
+  must be supported by the lowlevel driver also. Currently, the Teles
+  driver is the only voice-supporting one. See
+  Documentation/isdn/README.audio for more information.
+
+ICN 2B and 4B support
+CONFIG_ISDN_DRV_ICN
+  This enables support for two kinds of ISDN-cards made by a German
+  company called ICN. 2B is the standard version for a single ISDN
+  line with two B-channels, 4B supports two ISDN lines. For running
+  this card, additional firmware is necessary, which has to be
+  downloaded into the card using a utility which is distributed
+  separately.  See Documentation/isdn/README and README.icn for more
+  information.
+
+Teles, NICCY1016PC, Creatix support
+CONFIG_ISDN_DRV_TELES
+  This enables support for the Teles ISDN-cards S0-16.0, S0-16.3, S0-8
+  and many compatibles. By default, the driver is configured to
+  support a 16.0-type using EDSS1-protocol. See
+  Documentation/isdn/README on how to configure it using 16.3, a
+  different D-channel protocol, or non-standard irq/port/shmem
+  settings.
+
+PCBIT-D support
+CONFIG_ISDN_DRV_PCBIT
+  This enables support for the PCBIT ISDN-cards. This card is
+  manufactured in Portugal by Octal. For running this card, additional
+  firmware is necessary, which has to be downloaded into the card
+  using a utility which is distributed separately.  See
+  Documentation/isdn/README and Documentation/isdn/README.pcbit for
+  more information.
+
+Support for AP1000 multicomputer
+CONFIG_AP1000
+  This enables support for a sparc based parallel multi-computer
+  called an AP1000+. For details on our efforts to port Linux to this
+  machine see http://cap.anu.edu.au/cap/projects/linux or mail to
+  hackers@cafe.anu.edu.au
+
+Video mode selection support
+CONFIG_VIDEO_SELECT
+  This enables support for text mode selection on kernel startup. If you
+  want to take advantage of some high-resolution text mode your card's
+  BIOS offers, but the traditional Linux utilities like SVGATextMode
+  don't, you can enable this and set the mode using the "vga=" option
+  from your boot loader (LILO or LOADLIN) or set "vga=ask" which brings
+  up a video mode menu on kernel startup. Read Documentation/svga.txt
+  for more information. If unsure, say "n".
+
+# need an empty line after last entry, for sed script in Configure.
+
+#
+# This is used by ispell.el:
+#
+# LocalWords:  CONFIG coprocessor DX Pentium SX lilo loadlin HOWTO ftp sunsite
+# LocalWords:  unc edu docs emu README kB BLK DEV FD Thinkpad fd MFM RLL IDE gz
+# LocalWords:  cdrom harddisk diskless netboot nfs xzvf ATAPI MB harddrives ide
+# LocalWords:  HD harddisks CDROMs IDECD NEC MITSUMI filesystem XT XD PCI bios
+# LocalWords:  ISA EISA Microchannel VESA BIOSes IPC SYSVIPC ipc Ctrl dmesg hlt
+# LocalWords:  BINFMT Linkable http ac uk jo html GCC Sparc AVANTI CABRIOLET EB
+# LocalWords:  netscape gcc LD CC toplevel MODVERSIONS insmod rmmod modprobe IP
+# LocalWords:  genksyms INET loopback gatewaying ethernet internet PPP ARP Arp
+# LocalWords:  howto multicasting MULTICAST MBONE firewalling ipfw ACCT resp ip
+# LocalWords:  proc acct IPIP encapsulator decapsulator klogd PCTCP RARP EXT PS
+# LocalWords:  telneting subnetted NAGLE rlogin NOSR ttyS TGA techinfo mbone nl
+# LocalWords:  Mb SKB IPX Novell Netware dosemu Appletalk DDP ATALK tapedrive
+# LocalWords:  SD CHR scsi thingy SG CD LUNs LUN jukebox Adaptec BusLogic EATA
+# LocalWords:  buslogic DMA DPT ATT eata dma PIO UltraStor fdomain umsdos ext
+# LocalWords:  QLOGIC qlogic TMC seagate Trantor ultrastor FASST wd NETDEVICES
+# LocalWords:  unix BBS linux nullmodem CSLIP PLIP Kirch's LDP CSlip SL SCC IRQ
+# LocalWords:  Turbo Laplink plip NCSA port's ReQuest IRQs EQL SMC AMD PCnet NE
+# LocalWords:  COM ELPLUS Com EtherLinkIII VLB Arcnet arcnet Cabletron DEPCA DE
+# LocalWords:  depca EtherWorks EWRK ewrk SEEQ EtherExpressPro EEXPRESS NI xxx
+# LocalWords:  EtherExpress WaveLAN wavelan PCLAN HPLAN VG SK Ansel Xen de ZNET
+# LocalWords:  PCMCIA cb stanford pcmcia LAN TEC RealTek ATP atp DLINK NetTools
+# LocalWords:  TR Sony CDU caddyless cdu Mitsumi MCD cd mcd XA MultiSession CDA
+# LocalWords:  Matsushita Panasonic SBPCD Soundblaster Longshine sbpcd Aztech
+# LocalWords:  Okano Wearnes AZTCD CDD SE aztcd sonycd Goldstar GSCD Philips fs
+# LocalWords:  LMS OPTCD Sanyo SJCD minix faqs xiafs XIA msdos harddrive mtools
+# LocalWords:  std softlinks umssync NetworkFileSharing nfsd mountd CDs HPFS TI
+# LocalWords:  hpfs SYSV SCO intel iBCS Wyse WordPerfect tsx mit unixes sysv NR
+# LocalWords:  SMB WfW Cyclades async mux Logitech busmouse MouseSystem aka AST
+# LocalWords:  PSMOUSE Compaq trackballs Travelmate Inport ATIXL ATI busmice ld
+# LocalWords:  gpm config QIC DYNCONF FTAPE Stor Ftape ftape pcsndrv manpage NT
+# LocalWords:  readprofile diskdrives org com masq EtherTalk tcp netrom sunacm
+# LocalWords:  misc AIC aic pio nullmodems scc Portmaster eql GIS PhotoCDs MCDX
+# LocalWords:  mcdx gscd optcd sjcd ISP soundcard hdparm Workgroups Lan samba
+# LocalWords:  filesystems smbfs ATA ppp PCTech RZ www powerquest txt CMD ESDI
+# LocalWords:  chipset FB multicast MROUTE appletalk ifconfig IBMTR multiport
+# LocalWords:  Multisession STALDRV EasyIO EC EasyConnection ISTALLION ONboard
+# LocalWords:  Brumby pci TNC cis ohio faq usenet NETLINK dev hydra ca Tyne mem
+# LocalWords:  carleton Deskstation DECstation SUNFD JENSEN Noname XXXM SLiRP
+# LocalWords:  pppd Zilog ZS soundcards SRM bootloader ez mainmenu rarp ipfwadm
+# LocalWords:  RTNETLINK mknod xos MTU lwared Macs mac netatalk macs cs Wolff
+# LocalWords:  dartmouth flowerpt MultiMaster FlashPoint tudelft etherexpress
+# LocalWords:  ICL EtherTeam ETH IDESCSI TXC SmartRAID SmartCache httpd sjc dlp
+# LocalWords:  thesphere TwoServers BOOTP DHCP ncpfs BPQETHER BPQ chipsets MG
+# LocalWords:  bsd comp Sparcstation le SunOS ie Gracilis PackeTwin PT pt LU FX
+# LocalWords:  FX TEAC SoundBlaster CR CreativeLabs LCS mS ramdisk IDETAPE cmd
+# LocalWords:  Vertos Genoa Funai hsfs NCP NetWare tgz APM apm ioctls UltraLite
+# LocalWords:  TravelMate CDT LCD backlight VC RPC Mips DECStation AXP barlow
+# LocalWords:  PMAX MILO Alphas Multia Tseng linuxelf endian mipsel mips drv HT
+# LocalWords:  KERNELD kerneld callouts AdvanSys advansys diskquotas Admin WDT
+# LocalWords:  wdt hdb hdc bugfix SiS vlb Acculogic CSA DTC dtc Holtek ht QDI
+# LocalWords:  QD qd UMC umc ALI ali lena fnet fr homepage azstarnet axplinux
+# LocalWords:  Avanti XL AlphaStations Jensen DECpc AXPpci UDB Cabriolet MCA RC
+# LocalWords:  AlphaPC uwaterloo cpbeaure mca AOUT OUTput PPro sipx gwdg lo nwe
+# LocalWords:  Keepalive linefill RELCOM keepalive analogue CDR conf CDI INIT
+# LocalWords:  OPTi isp irq noisp VFAT vfat NTFS losetup dmsdosfs dosfs ISDN MP
+# LocalWords:  NOWAYOUT behaviour dialin isdn callback BTX Teles ICN EDSS Cisco
+# LocalWords:  ipppd syncppp RFC MPP VJ downloaded icn NICCY Creatix shmem ufr
+# LocalWords:  ibp md ARCnet ether encap NDIS arcether ODI Amigas AmiTCP NetBSD
+# LocalWords:  initrd tue util DES funet des OnNet BIOSP smc Travan Iomega CMS
+# LocalWords:  FC DC dc PPA IOMEGA's ppa RNFS FMV Fujitsu ARPD arpd loran layes
+# LocalWords:  FRAD indiana framerelay DLCI DCLIs Sangoma SDLA mrouted sync sec
+# LocalWords:  Starmode Metricom MosquitoNet mosquitonet kbit nfsroot Digiboard
+# LocalWords:  DIGI Xe Xeve digiboard UMISC touchscreens mtu ethernets HBAs MEX
+# LocalWords:  Shifflett netcom js jshiffle WIC DECchip ELCP EtherPower dst RTC
+# LocalWords:  rtc SMP lp Digi Intl RightSwitch DGRS dgrs AFFS Amiga UFS SDL AP
+# LocalWords:  Solaris RISCom riscom syncPPP PCBIT pcbit sparc anu au artoo ufs
+# LocalWords:  hitchcock Crynwr cnam pktdrvr NCSA's CyDROM CyCDROM FreeBSD NeXT
+# LocalWords:  NeXTstep disklabel disklabels SMD FFS tm AmigaOS diskfiles Un IQ
+# LocalWords:  Bernd informatik rwth aachen uae affs multihosting bytecode java
+# LocalWords:  applets applet JDK ncsa cabi SNI Alphatronix readme LANs scarab
+# LocalWords:  winsock RNIS caltech OSPF honour Honouring Mbit Localtalk DEFRAG
+# LocalWords:  localtalk download Packetwin Baycom baycom interwork ascii JNT
+# LocalWords:  Camtec proxying indyramp defragment defragmented UDP FAS FASXX
+# LocalWords:  FastSCSI SIO FDC qlogicfas QLogic qlogicisp setbaycom ife ee LJ
+# LocalWords:  ethz ch Travelmates ProAudioSpectrum ProAudio SoundMan SB SBPro
+# LocalWords:  Thunderboard SM OPL FM ADLIB TSR Gravis MPU PSS ADI SW DSP codec
+# LocalWords:  ADSP ESC ASIC daughtercard GUSMAX MSS NX AdLib Excell Ensoniq YM
+# LocalWords:  SoundScape Spea MediaTriX AudioTriX WSS OTI ThunderBoard VoxWare
+# LocalWords:  Soundscape SSCAPE TRIX MediaTrix PnP Maui dsp midixx EIA getty
+# LocalWords:  mgetty sendfax gert greenie muc lowlevel Lasermate LanManager io
+# LocalWords:  OOPSes trackball binghamton mobileip ncr IOMAPPED settags ns ser
+# LocalWords:  setsync NEGO MPARITY autotuning prefetch PIIX cdwrite utils rc
+# LocalWords:  PCWATCHDOG berkprod bitgate
diff --git a/Documentation/IO-mapping.txt b/Documentation/IO-mapping.txt
new file mode 100644
index 000000000..ceac953e4
--- /dev/null
+++ b/Documentation/IO-mapping.txt
@@ -0,0 +1,202 @@
+
+[ This is a mail-message in response to a query on IO mapping, thus the
+  strange format for a "document" ]
+
+The aha1542 is a bus-master device, and your patch makes the driver give the
+controller the physical address of the buffers, which is correct on x86
+(because all bus master devices see the physical memory mappings directly). 
+
+However, on many setups, there are actually _three_ different ways of looking
+at memory addresses, and in this case we actually want the third, the
+so-called "bus address". 
+
+Essentially, the three ways of addressing memory are (this is "real memory",
+ie normal RAM, see later about other details): 
+
+ - CPU untranslated. This is the "physical" address, ie physical address 
+   0 is what the CPU sees when it drives zeroes on the memory bus.
+
+ - CPU translated address. This is the "virtual" address, and is 
+   completely internal to the CPU itself with the CPU doing the appropriate
+   translations into "CPU untranslated". 
+
+ - bus address. This is the address of memory as seen by OTHER devices, 
+   not the CPU. Now, in theory there could be many different bus 
+   addresses, with each device seeing memory in some device-specific way, but
+   happily most hardware designers aren't actually actively trying to make
+   things any more complex than necessary, so you can assume that all 
+   external hardware sees the memory the same way. 
+
+Now, on normal PC's the bus address is exactly the same as the physical
+address, and things are very simple indeed. However, they are that simple
+because the memory and the devices share the same address space, and that is
+not generally necessarily true on other PCI/ISA setups. 
+
+Now, just as an example, on the PReP (PowerPC Reference Platform), the 
+CPU sees a memory map something like this (this is from memory):
+
+	0-2GB	"real memory"
+	2GB-3GB	"system IO" (ie inb/out type accesses on x86)
+	3GB-4GB "IO memory" (ie shared memory over the IO bus)
+
+Now, that looks simple enough. However, when you look at the same thing from
+the viewpoint of the devices, you have the reverse, and the physical memory
+address 0 actually shows up as address 2GB for any IO master.
+
+So when the CPU wants any bus master to write to physical memory 0, it 
+has to give the master address 0x80000000 as the memory address.
+
+So, for example, depending on how the kernel is actually mapped on the 
+PPC, you can end up with a setup like this:
+
+ physical address:	0
+ virtual address:	0xC0000000
+ bus address:		0x80000000
+
+where all the addresses actually point to the same thing, it's just seen 
+through different translations..
+
+Similarly, on the alpha, the normal translation is
+
+ physical address:	0
+ virtual address:	0xfffffc0000000000
+ bus address:		0x40000000
+
+(but there are also alpha's where the physical address and the bus address
+are the same). 
+
+Anyway, the way to look up all these translations, you do
+
+	#include <asm/io.h>
+
+	phys_addr = virt_to_phys(virt_addr);
+	virt_addr = phys_to_virt(phys_addr);
+	 bus_addr = virt_to_bus(virt_addr);
+	virt_addr = bus_to_virt(bus_addr);
+
+Now, when do you need these?
+
+You want the _virtual_ address when you are actually going to access that 
+pointer from the kernel. So you can have something like this:
+
+	/*
+	 * this is the hardware "mailbox" we use to communicate with
+	 * the controller. The controller sees this directly.
+	 */
+	struct mailbox {
+		__u32 status;
+		__u32 bufstart;
+		__u32 buflen;
+		..
+	} mbox;
+
+		unsigned char * retbuffer;
+
+		/* get the address from the controller */
+		retbuffer = bus_to_virt(mbox.bufstart);
+		switch (retbuffer[0]) {
+			case STATUS_OK:
+				...
+
+on the other hand, you want the bus address when you have a buffer that 
+you want to give to the controller:
+
+	/* ask the controller to read the sense status into "sense_buffer" */
+	mbox.bufstart = virt_to_bus(&sense_buffer);
+	mbox.buflen = sizeof(sense_buffer);
+	mbox.status = 0;
+	notify_controller(&mbox);
+
+And you generally _never_ want to use the physical address, because you can't
+use that from the CPU (the CPU only uses translated virtual addresses), and
+you can't use it from the bus master. 
+
+So why do we care about the physical address at all? We do need the physical
+address in some cases, it's just not very often in normal code.  The physical
+address is needed if you use memory mappings, for example, because the
+"remap_page_range()" mm function wants the physical address of the memory to
+be remapped (the memory management layer doesn't know about devices outside
+the CPU, so it shouldn't need to know about "bus addresses" etc). 
+
+NOTE NOTE NOTE! The above is only one part of the whole equation. The above
+only talks about "real memory", ie CPU memory, ie RAM. 
+
+There is a completely different type of memory too, and that's the "shared
+memory" on the PCI or ISA bus. That's generally not RAM (although in the case
+of a video graphics card it can be normal DRAM that is just used for a frame
+buffer), but can be things like a packet buffer in a network card etc. 
+
+This memory is called "PCI memory" or "shared memory" or "IO memory" or
+whatever, and there is only one way to access it: the readb/writeb and
+related functions. You should never take the address of such memory, because
+there is really nothing you can do with such an address: it's not
+conceptually in the same memory space as "real memory" at all, so you cannot
+just dereference a pointer. (Sadly, on x86 it _is_ in the same memory space,
+so on x86 it actually works to just deference a pointer, but it's not
+portable). 
+
+For such memory, you can do things like
+
+ - reading:
+	/*
+	 * read first 32 bits from ISA memory at 0xC0000, aka
+	 * C000:0000 in DOS terms
+	 */
+	unsigned int signature = readl(0xC0000);
+
+ - remapping and writing:
+	/*
+	 * remap framebuffer PCI memory area at 0xFC000000,
+	 * size 1MB, so that we can access it: We can directly
+	 * access only the 640k-1MB area, so anything else
+	 * has to be remapped.
+	 */
+	char * baseptr = ioremap(0xFC000000, 1024*1024);
+
+	/* write a 'A' to the offset 10 of the area */
+	writeb('A',baseptr+10);
+
+	/* unmap when we unload the driver */
+	iounmap(baseptr);
+
+ - copying and clearing:
+	/* get the 6-byte ethernet address at ISA address E000:0040 */
+	memcpy_fromio(kernel_buffer, 0xE0040, 6);
+	/* write a packet to the driver */
+	memcpy_toio(0xE1000, skb->data, skb->len);
+	/* clear the frame buffer */
+	memset_io(0xA0000, 0, 0x10000);
+
+Ok, that just about covers the basics of accessing IO portably.  Questions?
+Comments? You may think that all the above is overly complex, but one day you
+might find yourself with a 500MHz alpha in front of you, and then you'll be
+happy that your driver works ;)
+
+Note that kernel versions 2.0.x (and earlier) mistakenly called the
+ioremap() function "vremap()".  ioremap() is the proper name, but I
+didn't think straight when I wrote it originally.  People who have to
+support both can do something like:
+ 
+	/* support old naming sillyness */
+	#if LINUX_VERSION_CODE < 0x020100                                     
+	#define ioremap vremap
+	#define iounmap vfree                                                     
+	#endif
+ 
+at the top of their source files, and then they can use the right names
+even on 2.0.x systems. 
+
+And the above sounds worse than it really is.  Most real drivers really
+don't do all that complex things (or rather: the complexity is not so
+much in the actual IO accesses as in error handling and timeouts etc). 
+It's generally not hard to fix drivers, and in many cases the code
+actually looks better afterwards:
+
+	unsigned long signature = *(unsigned int *) 0xC0000;
+		vs
+	unsigned long signature = readl(0xC0000);
+
+I think the second version actually is more readable, no?
+
+		Linus
+
diff --git a/Documentation/SMP.txt b/Documentation/SMP.txt
new file mode 100644
index 000000000..2295187b9
--- /dev/null
+++ b/Documentation/SMP.txt
@@ -0,0 +1,25 @@
+SMP support for Linux with up to 16 processors using the Intel MP
+specification. 
+
+WARNING:
+	This is experimental. Back up your disks first. Experience is that
+it is basically stable in its current (inefficient form).
+
+To fix:
+
+o	Fix sys_idle to exit/enter kernel state and do hlt's.
+o	Fix scheduler decisions to reschedule. Per cpu reschedule ?
+o	Clean up message pass.
+o	Test for B stepping processors.
+o	Clean up processor specific/independent split.
+o	Document it all.	[PARTLY DONE]
+o	Halt other CPU's on reset/panic doesn't always work.
+o	Don't waste page at 4K - don't need it now.(watch the GDT code).
+o	Dump bootup pages once booted somehow.
+o	Clean up warnings/volatiles.
+o	Fix load_TR() for non contiguous processor ids
+o	Iterate over the slave timer requests if one is lost (keep a count per cpu)
+o	Distribute irq's (locking present just needs the 82489 to be asked
+	nicely).
+o	486 startup code.
+o	How to handle mixed FPU/non FPU processors.
diff --git a/Documentation/cdrom/00-INDEX b/Documentation/cdrom/00-INDEX
new file mode 100644
index 000000000..f41a8f54f
--- /dev/null
+++ b/Documentation/cdrom/00-INDEX
@@ -0,0 +1,29 @@
+00-INDEX
+	- this file (info on CD-ROMs and Linux)
+aztcd
+	- info on Aztech/Orchid/Okano/Wearnes/Conrad/CyCDROM driver.
+cdrom-standard.tex
+	- LaTeX document on standardizing the CD-ROM programming interface.
+cdu31a
+	- info on the Sony CDU31A/CDU33A CD-ROM driver.
+cm206
+	- info on the Philips/LMS cm206/cm260 CD-ROM driver.
+gscd
+	- info on the Goldstar R420 CD-ROM driver.
+ide-cd
+	- info on setting up and using ATAPI (aka IDE) CD-ROMs.
+isp16
+	- info on the CD-ROM interface on ISP16, MAD16 or Mozart sound card.
+mcd
+	- info on limitations of standard Mitsumi CD-ROM driver.
+mcdx
+	- info on improved Mitsumi CD-ROM driver.
+optcd
+	- info on the Optics Storage 8000 AT CD-ROM driver
+sbpcd
+	- info on the SoundBlaster/Panasonic CD-ROM interface driver.
+sjcd
+	- info on the SANYO CDR-H94A CD-ROM interface driver.
+sonycd535
+	- info on the Sony CDU-535 (and 531) CD-ROM driver.
+
diff --git a/Documentation/cdrom/aztcd b/Documentation/cdrom/aztcd
new file mode 100644
index 000000000..a0832d340
--- /dev/null
+++ b/Documentation/cdrom/aztcd
@@ -0,0 +1,810 @@
+$Id: README.aztcd,v 2.50 1996/05/16 18:31:22 root Exp root $
+          Readme-File /usr/src/Documentation/cdrom/aztcd
+           			for 
+	     AZTECH CD-ROM CDA268-01A, ORCHID CD-3110,
+      OKANO/WEARNES CDD110, CONRAD TXC, CyCDROM CR520, CR540
+                           CD-ROM Drives 
+                       Version 2.5 and newer
+                   (for other drives see 6.-8.)
+
+NOTE: THIS DRIVER WILL WORK WITH THE CD-ROM DRIVES LISTED, WHICH HAVE
+      A PROPRIETARY INTERFACE (implemented on a sound card or on an
+      ISA-AT-bus card). 
+      IT WILL DEFINITELY NOT WORK WITH CD-ROM DRIVES WITH *IDE*-INTERFACE,
+      such as the Aztech CDA269-031SE !!! (The only known exceptions are
+      'faked' IDE drives like the CyCDROM CR520ie which work with aztcd
+      under certain conditions, see 7.). IF YOU'RE USING A CD-ROM DRIVE
+      WITH IDE-INTERFACE, SOMETIMES ALSO CALLED ATAPI-COMPATIBLE, PLEASE 
+      USE THE ide-cd.c DRIVER, WRITTEN BY MARK LORD AND SCOTT SNYDER !
+      THE STANDARD-KERNEL 1.2.x NOW ALSO SUPPORTS IDE-CDROM-DRIVES, SEE THE
+      HARDDISK (!) SECTION OF make config, WHEN COMPILING A NEW KERNEL!!!
+----------------------------------------------------------------------------
+
+Contents of this file:
+                         1.  NOTE
+                         2.  INSTALLATION
+                         3.  CONFIGURING YOUR KERNEL
+                         4.  RECOMPILING YOUR KERNEL
+                         4.1   AZTCD AS A RUN-TIME LOADABLE MODULE
+                         4.2   CDROM CONNECTED TO A SOUNDCARD
+                         5.  KNOWN PROBLEMS, FUTURE DEVELOPMENTS
+			 5.1   MULTISESSION SUPPORT
+			 5.2   STATUS RECOGNITION
+			 5.3   DOSEMU's CDROM SUPPORT
+                         6.  BUG REPORTS
+                         7.  OTHER DRIVES
+                         8.  IF YOU DON'T SUCCEED ... DEBUGGING  
+                         9.  TECHNICAL HISTORY OF THE DRIVER
+                        10.  ACKNOWLEDGMENTS
+                        11.  PROGRAMMING ADD ONS: CDPLAY.C
+                        APPENDIX: Source code of cdplay.c
+----------------------------------------------------------------------------
+
+1. NOTE 
+This software has been successfully in alpha and beta test and is part of
+the standard kernel since kernel 1.1.8x since December 1994. It works with
+with AZTECH CDA268-01A, ORCHID CDS-3110, ORCHID/WEARNES CDD110 and
+CONRAD TXC (Nr.99 31 23 -series 04) and has proven to be stable with kernel 
+versions 1.0.9 to 1.3.72. But with any software there still may be bugs in it. 
+So if you encounter problems, you are invited to help us improve this software. 
+Please send me a detailed bug report (see chapter BUG REPORTS). You are also 
+invited in helping us to increase the number of drives, which are supported.
+
+Please read the README-files carefully and always keep a backup copy of your 
+old kernel, in order to reboot if something goes wrong!
+
+2. INSTALLATION
+The driver consists of a header file 'aztcd.h', which normally should reside 
+in /usr/include/linux and the source code 'aztcd.c', which normally resides in
+/usr/src/linux/drivers/cdrom. It uses /dev/aztcd (/dev/aztcd0 in some distri-
+butions), which must be a valid block device with major number 29 and reside 
+in directory /dev. To mount a CD-ROM, your kernel needs to have the ISO9660-
+filesystem support included.
+
+PLEASE NOTE: aztcd.c has been developed in parallel to the linux kernel,
+which had and is having many major and minor changes which are not backward
+compatible. Quite definitely aztcd.c version 1.80 and newer will NOT work
+in kernels older than 1.3.33. So please always use the most recent version
+of aztcd.c with the appropriate linux-kernel.
+
+3.  CONFIGURING YOUR KERNEL
+If your kernel is already configured for using the AZTECH driver you will
+see the following message while Linux boots:
+    Aztech CD-ROM Init: DriverVersion=<version number> BaseAddress=<baseaddress>
+    Aztech CD-ROM Init: FirmwareVersion=<firmware version id of your I/O-card>>>
+    Aztech CD-ROM Init: <drive type> detected
+    Aztech CD-ROM Init: End
+If the message looks different and you are sure to have a supported drive,
+it may have a different base address. The Aztech driver does look for the 
+CD-ROM drive at the base address specified in aztcd.h at compile time. This 
+address can be overwritten by boot parameter aztcd=....You should reboot and 
+start Linux with boot parameter aztcd=<base address>, e.g. aztcd=0x320. If 
+you do not know the base address, start your PC with DOS and look at the boot 
+message of your CD-ROM's DOS driver. If that still does not help, use boot
+parameter aztcd=<base address>,0x79 , this tells aztcd to try a little harder.
+
+If the message looks correct, as user 'root' you should be able to mount the 
+drive by
+          mount -t iso9660 -r /dev/aztcd0 /mnt
+and use it as any other filesystem. (If this does not work, check if
+/dev/aztcd0 and /mnt do exist and create them, if necessary by doing
+      mknod /dev/aztcd0 b 29 0
+      mkdir /mnt                       
+
+If you still get a different message while Linux boots or when you get the 
+message, that the ISO9660-filesystem is not supported by your kernel, when
+you try to mount the CD-ROM drive, you have to recompile your kernel.
+
+If you do *not* have an Aztech/Orchid/Okano/Wearnes/TXC drive and want to 
+bypass drive detection during Linux boot up, start with boot parameter aztcd=0.
+
+Most distributions nowadays do contain a boot disk image containing aztcd.
+Please note, that this driver will not work with IDE/ATAPI drives! With these 
+you must use ide-cd.c instead.
+
+4. RECOMPILING YOUR KERNEL
+If your kernel is not yet configured for the AZTECH driver and the ISO9660-
+filesystem, you have to recompile your kernel: 
+
+- Edit aztcd.h to set the I/O-address to your I/O-Base address (AZT_BASE_ADDR), 
+  the driver does not use interrupts or DMA, so if you are using an AZTECH
+  CD268, an ORCHID CD-3110 or ORCHID/WEARNES CDD110 that's the only item you 
+  have to set up. If you have a soundcard, read chapter 4.2.
+  Users of other drives should read chapter OTHER DRIVES of this file.
+  You also can configure that address by kernel boot parameter aztcd=... 
+- There are some other points, which may be configured, e.g. auto-eject the
+  CD when unmounting a drive, tray locking etc., see aztcd.h for details.
+- Build a new kernel, configure it for 'Aztech/Orchid/Okano/Wearnes support' 
+  (if you want aztcd to be part of the kernel). Do not configure it for
+  'Aztech... support', if you want to use aztcd as a run time loadable module. 
+  But in any case you must have the ISO9660-filesystem included in your
+  kernel.
+- Activate the new kernel, normally this is done by running LILO (don't for-
+  get to configure it before and to keep a copy of your old kernel in case
+  something goes wrong!).
+- Reboot
+- If you've included aztcd in your kernel, you now should see during boot 
+  some messages like
+    Aztech CD-ROM Init: DriverVersion=<version number> BaseAddress=<baseaddress>
+    Aztech CD-ROM Init: FirmwareVersion=<firmware version id of your I/O-card>
+    Aztech CD-ROM Init: <drive type> detected
+    Aztech CD-ROM Init: End
+- If you have not included aztcd in your kernel, but want to load aztcd as a 
+  run time loadable module see 4.1. 
+- If the message looks correct, as user 'root' you should be able to mount 
+  the drive by
+          mount -t iso9660 -r /dev/aztcd0 /mnt
+  and use it as any other filesystem. (If this does not work, check if
+  /dev/aztcd0 and /mnt do exist and create them, if necessary by doing
+      mknod /dev/aztcd0 b 29 0
+      mkdir /mnt                       
+- If this still does not help, see chapters OTHER DRIVES and DEBUGGING.
+
+4.1 AZTCD AS A RUN-TIME LOADABLE MODULE
+If you do not need aztcd permanently, you can also load and remove the driver
+during runtime via insmod and rmmod. To build aztcd as a loadable module you 
+must configure your kernel for AZTECH module support (answer 'm' when con-
+figuring the kernel). Anyhow, you may run into problems, if the version of 
+your boot kernel is not the same than the source kernel version, from which 
+you create the modules. So rebuild your kernel, if necessary. 
+
+Now edit the base address of your AZTECH interface card in
+/usr/src/linux/include/linux/aztcd.h to the appropriate value. There are
+also some special features which may be configured, e.g. auto-eject a CD
+when unmounting the drive etc; see aztcd.h for details. Then change
+to /usr/src/linux and do a 
+                    make modules  
+	            make modules_install
+After that you can run-time load the driver via
+                    insmod /lib/modules/X.X.X/misc/aztcd.o
+and remove it via   rmmod  aztcd.
+If you did not set the correct base address in aztcd.h, you can also supply the
+base address when loading the driver via
+                    insmod /lib/modules/X.X.X/misc/aztcd.o aztcd=<base address>
+If you do not have the iso9660-filesystem in your boot kernel, you also have
+to load it before you can mount the CDROM:
+                    insmod /lib/modules/X.X.X/fs/isofs.o
+The mount procedure works as described in 4. above.
+(In all commands 'X.X.X' is the current linux kernel version number. For details
+see file modules.txt in /usr/src/linux/Documentation)
+
+4.2 CDROM CONNECTED TO A SOUNDCARD
+Most soundcards do have a bus interface to the CDROM-drive. In many cases
+this soundcard needs to be configured, before the CDROM can be used. This
+configuration procedure consists of writing some kind of initialization
+data to the soundcard registers. The AZTECH-CDROM driver in the moment does
+only support one type of soundcard (SoundWave32). Users of other soundcards
+should try to boot DOS first and let their DOS drivers initialize the
+soundcard and CDROM, then warm boot (or use loadlin) their PC to start
+Linux.
+Support for the CDROM-interface of SoundWave32-soundcards is directly
+implemented in the AZTECH driver. Please edit /usr/src/linux/include/aztdc.h,
+uncomment line '#define AZT_SW32' and set the appropriate value for
+AZT_BASE_ADDR and AZT_SW32_BASE_ADDR. This support was tested with an Orchid
+CDS-3110 connected to a SoundWave32.
+If you want your soundcard to be supported, find out, how it needs to be
+configured and mail me (see 6.) the appropriate information. 
+
+5. KNOWN PROBLEMS, FUTURE DEVELOPMENTS
+5.1 MULTISESSION SUPPORT
+Multisession support for CD's still is a myth. I implemented and tested a basic
+support for multisession and XA CDs, but I still have not enough CDs and appli-
+cations to test it rigourously. So if you'd like to help me, please contact me
+(Email address see below). As of version 1.4 and newer you can enable the 
+multisession support in aztcd.h by setting AZT_MULTISESSION to 1. Doing so 
+will cause the ISO9660-filesystem to deal with multisession CDs, ie. redirect 
+requests to the Table of Contents (TOC) information from the last session, 
+which contains the info of all previous sessions etc.. If you do set 
+AZT_MULTISESSION to 0, you can use multisession CDs anyway. In that case the 
+drive's firmware will do automatic redirection. For the ISO9660-filesystem any 
+multisession CD  will then look like a 'normal' single session CD. But never-
+theless the data of all sessions are viewable and accessible. So with practical-
+ly all real world applications you won't notice the difference. But as future
+applications may make use of advanced multisession features, I've started to
+implement the interface for the ISO9660 multisession interface via ioctl
+CDROMMULTISESSION.
+
+5.2 STATUS RECOGNITION
+The drive status recognition does not work correctly in all cases. Changing
+a disk or having the door open, when a drive is already mounted, is detected 
+by the Aztech driver itself, but nevertheless causes multiple read attempts
+by the different layers of the ISO9660-filesystem driver, which finally timeout,
+so you have to wait quite a little... But isn't it bad style to change a disk 
+in a mounted drive, anyhow ?!
+
+The driver uses busy wait in most cases for the drive handshake (macros
+STEN_LOW and DTEN_LOW). I tested with a 486/DX2 at 66MHz and a Pentium at
+60MHz and 90MHz. Whenever you use a much faster machine you are likely to get 
+timeout messages. In that case edit aztcd.h and increase the timeout value 
+AZT_TIMEOUT. 
+
+For some 'slow' drive commands I implemented waiting with a timer waitqueue
+(macro STEN_LOW_WAIT). If you get this timeout message, you may also edit
+aztcd.h and increase the timeout value AZT_STATUS_DELAY. The waitqueue has
+shown to be a little critical. If you get kernel panic messages, edit aztcd.c
+and substitute STEN_LOW_WAIT by STEN_LOW. Busy waiting with STEN_LOW is more
+stable, but also causes CPU overhead.
+
+5.3 DOSEMU's CD-ROM SUPPORT
+With release 1.20 aztcd was modified to allow access to CD-ROMS when running
+under dosemu-0.60.0 aztcd-versions before 1.20 are most likely to crash
+Linux, when a CD-ROM is accessed under dosemu. This problem has partly been
+fixed, but still when accessing a directory for the first time the system
+might hang for some 30sec. So be patient, when using dosemu's CD-ROM support
+in combination with aztcd :-) ! 
+This problem has now (July 1995) been fixed by a modification to dosemu's
+CD-ROM driver. The new version came with dosemu-0.60.2, see dosemu's
+README.CDROM.
+
+6. BUG REPORTS
+Please send detailed bug reports and bug fixes via EMail to
+
+        zimmerma@rz.fht-esslingen.de
+
+Please include a description of your CD-ROM drive type and interface card, 
+the exact firmware message during Linux bootup, the version number of the 
+AZTECH-CDROM-driver and the Linux kernel version. Also a description of your 
+system's other hardware could be of interest, especially microprocessor type, 
+clock frequency, other interface cards such as soundcards, ethernet adapter, 
+game cards etc..
+
+I will try to collect the reports and make the necessary modifications from 
+time to time. I may also come back to you directly with some bug fixes and 
+ask you to do further testing and debugging.
+
+Editors of CD-ROMs are invited to send a 'cooperation' copy of their
+CD-ROMs to the volunteers, who provided the CD-ROM support for Linux. My
+snail mail address for such 'stuff' is
+           Prof. Dr. W. Zimmermann
+           Fachhochschule fuer Technik Esslingen
+           Fachbereich IT
+           Flandernstrasse 101
+           D-73732 Esslingen
+           Germany
+
+
+7. OTHER DRIVES
+The following drives ORCHID CDS3110, OKANO CDD110, WEARNES CDD110 and Conrad
+TXC Nr. 993123-series 04 nearly look the same as AZTECH CDA268-01A, especially 
+they seem to use the same command codes. So it was quite simple to make the 
+AZTECH driver work with these drives. 
+
+Unfortunately I do not have any of these drives available, so I couldn't test
+it myself. In some installations, it seems necessary to initialize the drive 
+with the DOS driver before (especially if combined with a sound card) and then 
+do a warm boot (CTRL-ALT-RESET) or start Linux from DOS, e.g. with 'loadlin'.
+
+If you do not succeed, read chapter DEBUGGING. Thanks in advance!
+
+Sorry for the inconvenience, but it is difficult to develop for hardware, 
+which you don't have available for testing. So if you like, please help us.
+
+If you do have a CyCDROM CR520ie thanks to Hilmar Berger's help your chances
+are good, that it will work with aztcd. The CR520ie is sold as an IDE-drive
+and really is connected to the IDE interface (primary at 0x1F0 or secondary
+at 0x170, configured as slave, not as master). Nevertheless it is not ATAPI
+compatible but still uses Aztech's command codes.
+
+
+8. DEBUGGING : IF YOU DON'T SUCCEED, TRY THE FOLLOWING
+-reread the complete README file
+-make sure, that your drive is hardware configured for 
+    transfer mode: polled
+    IRQ:           not used
+    DMA:           not used
+    Base Address:  something like 300, 320 ...
+ You can check this, when you start the DOS driver, which came with your
+ drive. By appropriately configuring the drive and the DOS driver you can
+ check, whether your drive does operate in this mode correctly under DOS. If
+ it does not operate under DOS, it won't under Linux.
+ If your drive's base address is something like 0x170 or 0x1F0 (and it is
+ not a CyCDROM CR520ie or CR 940ie) you most likely are having an IDE/ATAPI-
+ compatible drive, which is not supported by aztcd.c, use ide-cd.c instead.
+ Make sure the Base Address is configured correctly in aztcd.h, also make
+ sure, that /dev/aztcd0 exists with the correct major number (compare it with
+ the entry in file /usr/include/linux/major.h for the Aztech drive). 
+-insert a CD-ROM and close the tray
+-cold boot your PC (i.e. via the power on switch or the reset button)
+-if you start Linux via DOS, e.g. using loadlin, make sure, that the DOS
+ driver for the CD-ROM drive is not loaded (comment out the calling lines 
+ in DOS' config.sys!)
+-look for the aztcd: init message during Linux init and note them exactly
+-log in as root and do a mount -t iso9660 /dev/aztcd0 /mnt
+-if you don't succeed in the first time, try several times. Try also to open
+ and close the tray, then mount again. Please note carefully all commands
+ you typed in and the aztcd-messages, which you get.
+-if you get an 'Aztech CD-ROM init: aborted' message, read the remarks about
+ the version string below.
+
+If this does not help, do the same with the following differences 
+-start DOS before; make now sure, that the DOS driver for the CD-ROM is 
+ loaded under DOS (i.e. uncomment it again in config.sys)
+-warm boot your PC (i.e. via CTRL-ALT-DEL)
+ if you have it, you can also start via loadlin (try both).
+ ...
+ Again note all commands and the aztcd-messages.
+
+If you see STEN_LOW or STEN_LOW_WAIT error messages, increase the timeout
+values.
+
+If this still does not help, 
+-look in aztcd.c for the lines  #if 0
+                                #define AZT_TEST1
+                                ...
+                                #endif
+ and substitute '#if 0' by '#if 1'.
+-recompile your kernel and repeat the above two procedures. You will now get 
+ a bundle of debugging messages from the driver. Again note your commands
+ and the appropriate messages. If you have syslogd running, these messages
+ may also be found in syslogd's kernel log file. Nevertheless in some
+ installations syslogd does not yet run, when init() is called, thus look for
+ the aztcd-messages during init, before the login-prompt appears.
+ Then look in aztcd.c, to find out, what happened. The normal calling sequence 
+ is: aztcd_init() during Linux bootup procedure init()
+ after doing a 'mount -t iso9660 /dev/aztcd0 /mnt' the normal calling sequence is
+     aztcd_open()    -> Status 2c after cold reboot with CDROM or audio CD inserted
+                     -> Status 8  after warm reboot with CDROM inserted          
+                     -> Status 2e after cold reboot with no disk, closed tray
+                     -> Status 6e after cold reboot, mount with door open
+     aztUpdateToc()
+     aztGetDiskInfo()
+     aztGetQChannelInfo()   repeated several times
+     aztGetToc()
+     aztGetQChannelInfo()   repeated several times
+     a list of track information
+     do_aztcd_request()  }  
+     azt_transfer()    } repeated several times
+     azt_poll          }
+ Check, if there is a difference in the calling sequence or the status flags!
+ 
+ There are a lot of other messages, eg. the ACMD-command code (defined in
+ aztcd.h), status info from the getAztStatus-command and the state sequence of
+ the finite state machine in azt_poll(). The most important are the status
+ messages, look how they are defined and try to understand, if they make
+ sense in the context where they appear. With a CD-ROM inserted the status 
+ should always be 8, except in aztcd_open(). Try to open the tray, insert a
+ audio disk, insert no disk or reinsert the CD-ROM and check, if the status
+ bits change accordingly. The status bits are the most likely point, where 
+ the drive manufacturers may implement changes.
+            
+If you still don't succeed, a good point to start is to look in aztcd.c in 
+function aztcd_init, where the drive should be detected during init. Do the
+following:
+-reboot the system with boot parameter 'aztcd=<your base address>,0x79'. With
+ parameter 0x79 most of the drive version detection is bypassed. After that 
+ you should see the complete version string including leading and trailing 
+ blanks during init. 
+ Now adapt the statement
+      if ((result[1]=='A')&&(result[2]=='Z' ...)
+ in aztcd_init() to exactly match the first 3 or 4 letters you have seen.
+-Another point is the 'smart' card detection feature in aztcd_init(). Normally
+ the CD-ROM drive is ready, when aztcd_init is trying to read the version
+ string and a time consuming ACMD_SOFT_RESET command can be avoided. This is
+ detected by looking, if AFL_OP_OK can be read correctly. If the CD-ROM drive 
+ hangs in some unknown state, e.g. because of an error before a warm start or 
+ because you first operated under DOS, even the version string may be correct, 
+ but the following commands will not. Then change the code in such a way, 
+ that the ACMD_SOFT_RESET is issued in any case, by substituting the
+ if-statement 'if ( ...=AFL_OP_OK)' by 'if (1)'.
+
+If you succeed, please mail may the exact version string of your drive and
+the code modifications, you have made together with a short explanation.
+If you don't succeed, you may mail me the output of the debugging messages.
+But remember, they are only useful, if they are exact and complete and you
+describe in detail your hardware setup and what you did (cold/warm reboot,
+with/without DOS, DOS-driver started/not started, which Linux-commands etc.)
+
+
+9. TECHNICAL HISTORY OF THE DRIVER
+The AZTECH-Driver is a rework of the Mitsumi-Driver. Four major items had to
+be reworked:
+
+a) The Mitsumi drive does issue complete status information acknowledging
+each command, the Aztech drive does only signal that the command was
+processed. So whenever the complete status information is needed, an extra
+ACMD_GET_STATUS command is issued. The handshake procedure for the drive
+can be found in the functions aztSendCmd(), sendAztCmd() and getAztStatus().
+
+b) The Aztech Drive does not have a ACMD_GET_DISK_INFO command, so the
+necessary info about the number of tracks (firstTrack, lastTrack), disk
+length etc. has to be read from the TOC in the lead in track (see function
+aztGetDiskInfo()).
+
+c) Whenever data is read from the drive, the Mitsumi drive is started with a
+command to read an indefinite (0xffffff) number of sectors. When the appropriate 
+number of sectors is read, the drive is stopped by a ACDM_STOP command. This
+does not work with the Aztech drive. I did not find a way to stop it. The
+stop and pause commands do only work in AUDIO mode but not in DATA mode.
+Therefore I had to modify the 'finite state machine' in function azt_poll to
+only read a certain number of sectors and then start a new read on demand. As I 
+have not completely understood, how the buffer/caching scheme of the Mitsumi 
+driver was implemented, I am not sure, if I have covered all cases correctly, 
+whenever you get timeout messages, the bug is most likely to be in that
+function azt_poll() around switch(cmd) .... case ACD_S_DATA. 
+
+d) I did not get information about changing drive mode. So I doubt, that the
+code around function azt_poll() case AZT_S_MODE does work. In my test I have
+not been able to switch to reading in raw mode. For reading raw mode, Aztech
+uses a different command than for cooked mode, which I only have implemen-
+ted in the ioctl-section but not in the section which is used by the ISO9660- 
+
+The driver was developed on an AST PC with Intel 486/DX2, 8MB RAM, 340MB IDE 
+hard disk and on an AST PC with Intel Pentium 60MHz, 16MB RAM, 520MB IDE 
+running Linux kernel version 1.0.9 from the LST 1.8 Distribution. The kernel 
+was compiled with gcc.2.5.8. My CD-ROM drive is an Aztech CDA268-01A. My
+drive says, that it has Firmware Version AZT26801A1.3. It came with a ISA-bus
+interface card and works with polled I/O without DMA and without interrupts.
+The code for all other drives was 'remote' tested and debugged by a number of 
+volunteers on the Internet.
+
+Points, where I feel that possible problems might be and all points where I 
+did not completely understand the drive's behaviour or trust my own code are 
+marked with /*???*/ in the source code. There are also some parts in the 
+Mitsumi driver, where I did not completely understand their code.
+
+
+10. ACKNOWLEDGMENTS
+Without the help of P.Bush, Aztech, who delivered technical information
+about the Aztech Drive and without the help of E.Moenkeberg, GWDG, who did a
+great job in analyzing the command structure of various CD-ROM drives, this
+work would not have been possible. E.Moenkeberg was also a great help in 
+making the software 'kernel ready' and in answering many of the CDROM-related 
+questions in the newsgroups. He really is *the* Linux CD-ROM guru. Thanks 
+also to all the guys on the Internet, who collected valuable technical 
+information about CDROMs. 
+
+Joe Nardone (joe@access.digex.net) was a patient tester even for my first
+trial, which was more than slow, and made suggestions for code improvement.
+Especially the 'finite state machine' azt_poll() was rewritten by Joe to get
+clean C code and avoid the ugly 'gotos', which I copied from mcd.c.
+
+Robby Schirmer (schirmer@fmi.uni-passau.de) tested the audio stuff (ioctls) 
+and suggested a lot of patches for them.
+
+Joseph Piskor and Peter Nugent were the first users with the ORCHID CD3110
+and also were very patient with the problems which occurred.
+
+Reinhard Max delivered the information for the CDROM-interface of the
+SoundWave32 soundcards.
+
+Jochen Kunz and Olaf Kaluza delivered the information for supporting Conrad's 
+TXC drive.
+
+Hilmar Berger delivered the patches for supporting CyCDROM CR520ie.
+
+Anybody, who is interested in these items should have a look at 'ftp.gwdg.de',
+directory 'pub/linux/cdrom' and at 'ftp.cdrom.com', directory 'pub/cdrom'.
+
+11. PROGRAMMING ADD ONs: cdplay.c
+You can use the ioctl-functions included in aztcd.c in your own programs. As
+an example on how to do this, you will find a tiny CD Player for audio CDs 
+named 'cdplay.c'. It allows you to play audio CDs. You can play a specified 
+track, pause and resume or skip tracks forward and backwards. If you quit the 
+program without stopping the  drive, playing is continued. You can also 
+(mis)use cdplay to read and hexdump data disks. You can find the code in the 
+APPENDIX of this file, which you should cut out with an editor and store in a 
+separate file 'cdplay.c'. To compile it and make it executable, do
+  gcc -s -Wall -O2 -L/usr/lib cdplay.c -o /usr/local/bin/cdplay # compiles it
+  chmod +755 /usr/local/bin/cdplay                              # makes it executable
+  ln -s /dev/aztcd0 /dev/cdrom                                  # creates a link
+   (for /usr/lib substitute the top level directory, where your include files 
+    reside,  and for /usr/local/bin the directory, where you want the executable 
+    binary to reside )
+
+You have to set the correct permissions for cdplay *and* for /dev/mcd0 or
+/dev/aztcd0 in order to use it. Remember, that you should not have /dev/cdrom 
+mounted, when you're playing audio CDs. 
+
+This program is just a hack for testing the ioctl-functions in aztcd.c, I will 
+not maintain it, so if you run into problems, discard it or have a look into 
+the source code 'cdplay.c'. The program does only contain a minimum of user 
+protection and input error detection. If you use the commands in the wrong 
+order or if you try to read a CD at wrong addresses, you may get error messages
+or even hang your machine. If you get STEN_LOW, STEN_LOW_WAIT or segment violation 
+error messages when using cdplay, after that, the system might not be stable 
+any more, so you'd better reboot. As the ioctl-functions run in kernel mode,
+most normal Linux-multitasking protection features do not work. By using
+uninitialized 'wild' pointers etc., it is easy to write to other users data and
+program areas, destroy kernel tables etc.. So if you experiment with ioctls
+as always when you are doing systems programming and kernel hacking, you
+should have a backup copy of your system in a safe place (and you also
+should try before, how to restore from a backup copy)!
+
+A reworked and improved version called 'cdtester.c', which has yet more
+features for testing CDROM-drives can be found in
+/usr/src/linux/Documentation/cdrom/sbpcd, written by E.Moenkeberg.
+
+Werner Zimmermann
+Fachhochschule fuer Technik Esslingen
+(EMail: zimmerma@rz.fht-esslingen.de)
+Maerz 16, 1995
+
+---------------------------------------------------------------------------
+APPENDIX: Source code of cdplay.c
+
+/* Tiny Audio CD Player
+
+   Copyright 1994, 1995, 1996 Werner Zimmermann (zimmerma@rz.fht-esslingen.de)
+
+This program originally was written to test the audio functions of the
+AZTECH.CDROM-driver, but it should work with every CD-ROM drive. Before 
+using it, you should set a symlink from /dev/cdrom to your real CDROM
+device.
+
+The GNU General Public License applies to this program.
+
+History:  V0.1  W.Zimmermann: First release. Nov. 8, 1994
+          V0.2  W.Zimmermann: Enhanced functionality. Nov. 9, 1994
+          V0.3  W.Zimmermann: Additional functions. Nov. 28, 1994          
+          V0.4  W.Zimmermann: fixed some bugs. Dec. 17, 1994
+          V0.5  W.Zimmermann: clean 'scanf' commands without compiler warnings
+                              Jan. 6, 1995
+          V0.6  W.Zimmermann: volume control (still experimental). Jan. 24, 1995
+          V0.7  W.Zimmermann: read raw modified. July 26, 95
+*/
+
+#include <stdio.h>
+#include <ctype.h>
+#include <sys/ioctl.h>
+#include <sys/types.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <linux/cdrom.h>
+#include <linux/aztcd.h>
+
+void help(void)
+{ printf("Available Commands:  STOP         s      EJECT/CLOSE  e       QUIT         q\n");
+  printf("                     PLAY TRACK   t      PAUSE        p       RESUME       r\n");
+  printf("                     NEXT TRACK   n      REPEAT LAST  l       HELP         h\n");
+  printf("                     SUB CHANNEL  c      TRACK INFO   i       PLAY AT      a\n");
+  printf("                     READ         d      READ RAW     w       VOLUME       v\n");
+}
+
+int main(void)
+{ int handle;
+  unsigned char command=' ', ini=0, first=1, last=1;
+  unsigned int cmd, i,j,k, arg1,arg2,arg3;
+  struct cdrom_ti       ti;
+  struct cdrom_tochdr   tocHdr;
+  struct cdrom_subchnl  subchnl;
+  struct cdrom_tocentry entry;
+  struct cdrom_msf      msf;
+  union  { struct cdrom_msf msf;
+           unsigned char buf[CD_FRAMESIZE_RAW];
+         } azt;
+  struct cdrom_volctrl  volctrl;
+
+  printf("\nMini-Audio CD-Player V0.72   (C) 1994,1995,1996  W.Zimmermann\n");
+  handle=open("/dev/cdrom",O_RDWR);
+  ioctl(handle,CDROMRESUME);
+  
+  if (handle<=0) 
+    { printf("Drive Error: already playing, no audio disk, door open\n");
+      printf("             or no permission (you must be ROOT in order to use this program)\n");
+    }
+  else
+    { help();
+      while (1)
+        { printf("Type command (h = help):  ");
+          scanf("%s",&command); 
+          switch (command)
+            { case 'e':   cmd=CDROMEJECT;
+                          ioctl(handle,cmd);
+                          break;  
+              case 'p':   if (!ini)
+                             { printf("Command not allowed - play track first\n");
+                             }
+                          else
+                             { cmd=CDROMPAUSE;
+                               if (ioctl(handle,cmd)) printf("Drive Error\n");
+                             }
+                          break;
+              case 'r':   if (!ini)
+                             { printf("Command not allowed - play track first\n");
+                             }
+                          else
+                             { cmd=CDROMRESUME;
+                               if (ioctl(handle,cmd)) printf("Drive Error\n");
+                             }
+                          break;
+              case 's':   cmd=CDROMPAUSE;
+                          if (ioctl(handle,cmd)) printf("Drive error or already stopped\n");
+                          cmd=CDROMSTOP;
+                          if (ioctl(handle,cmd)) printf("Drive error\n");
+                          break;
+              case 't':   cmd=CDROMREADTOCHDR;
+                          if (ioctl(handle,cmd,&tocHdr)) printf("Drive Error\n");
+                          first=tocHdr.cdth_trk0;
+                          last= tocHdr.cdth_trk1;
+                          if ((first==0)||(first>last))
+                            { printf ("--could not read TOC\n");
+                            }
+                          else
+                            { printf("--first track: %d   --last track: %d   --enter track number: ",first,last);
+                              cmd=CDROMPLAYTRKIND;
+                              scanf("%i",&arg1);
+                              ti.cdti_trk0=arg1;
+                              if (ti.cdti_trk0<first) ti.cdti_trk0=first;
+                              if (ti.cdti_trk0>last)  ti.cdti_trk0=last;
+                              ti.cdti_ind0=0;
+                              ti.cdti_trk1=last;
+                              ti.cdti_ind1=0;
+                              if (ioctl(handle,cmd,&ti)) printf("Drive Error\n");
+                              ini=1;
+                            } 
+                          break;
+              case 'n':   if (!ini++) 
+                            { if (ioctl(handle,CDROMREADTOCHDR,&tocHdr)) printf("Drive Error\n");
+                              first=tocHdr.cdth_trk0;
+                              last= tocHdr.cdth_trk1;
+                              ti.cdti_trk0=first-1;
+                            }
+                          if ((first==0)||(first>last))
+                            { printf ("--could not read TOC\n");
+                            }
+                          else
+                            { cmd=CDROMPLAYTRKIND;
+                              if (++ti.cdti_trk0 > last)  ti.cdti_trk0=last;
+                              ti.cdti_ind0=0;
+                              ti.cdti_trk1=last;
+                              ti.cdti_ind1=0;
+                              if (ioctl(handle,cmd,&ti)) printf("Drive Error\n");
+                              ini=1;
+                            }
+                          break;
+              case 'l':   if (!ini++)
+                            { if (ioctl(handle,CDROMREADTOCHDR,&tocHdr)) printf("Drive Error\n");
+                              first=tocHdr.cdth_trk0;
+                              last= tocHdr.cdth_trk1;
+                              ti.cdti_trk0=first+1;
+                            }
+                          if ((first==0)||(first>last))
+                            { printf ("--could not read TOC\n");
+                            }
+                          else
+                            { cmd=CDROMPLAYTRKIND;
+                              if (--ti.cdti_trk0 < first) ti.cdti_trk0=first;
+                              ti.cdti_ind0=0;
+                              ti.cdti_trk1=last;
+                              ti.cdti_ind1=0;
+                              if (ioctl(handle,cmd,&ti)) printf("Drive Error\n");
+                              ini=1;
+                            }  
+                          break;
+              case 'c':   subchnl.cdsc_format=CDROM_MSF;
+                          if (ioctl(handle,CDROMSUBCHNL,&subchnl)) 
+                            printf("Drive Error\n");
+                          else
+                            { printf("AudioStatus:%s   Track:%d  Mode:%d   MSF=%d:%d:%d\n", \
+                              subchnl.cdsc_audiostatus==CDROM_AUDIO_PLAY ? "PLAYING":"NOT PLAYING",\
+                              subchnl.cdsc_trk,subchnl.cdsc_adr, \
+                              subchnl.cdsc_absaddr.msf.minute, subchnl.cdsc_absaddr.msf.second, \
+                              subchnl.cdsc_absaddr.msf.frame);
+                            }
+                          break;              
+              case 'i':   if (!ini)
+                            { printf("Command not allowed - play track first\n");
+                            }
+                          else
+                            { cmd=CDROMREADTOCENTRY;
+                              printf("Track No.: ");
+                              scanf("%d",&arg1);
+                              entry.cdte_track=arg1;
+                              if (entry.cdte_track<first) entry.cdte_track=first;
+                              if (entry.cdte_track>last)  entry.cdte_track=last;
+			      entry.cdte_format=CDROM_MSF;
+                              if (ioctl(handle,cmd,&entry)) 
+                               { printf("Drive error or invalid track no.\n");
+                               }
+                              else
+                               { printf("Mode %d Track, starts at %d:%d:%d\n", \
+                               entry.cdte_adr,entry.cdte_addr.msf.minute, \
+                               entry.cdte_addr.msf.second,entry.cdte_addr.msf.frame);
+                               }
+                            }
+                          break;
+              case 'a':   cmd=CDROMPLAYMSF;
+                          printf("Address (min:sec:frame)  ");
+                          scanf("%d:%d:%d",&arg1,&arg2,&arg3);
+                          msf.cdmsf_min0  =arg1;
+                          msf.cdmsf_sec0  =arg2;
+                          msf.cdmsf_frame0=arg3;
+                          if (msf.cdmsf_sec0  > 59) msf.cdmsf_sec0  =59;
+                          if (msf.cdmsf_frame0> 74) msf.cdmsf_frame0=74;
+                          msf.cdmsf_min1=60;
+                          msf.cdmsf_sec1=00;
+                          msf.cdmsf_frame1=00;
+                          if (ioctl(handle,cmd,&msf)) 
+                           { printf("Drive error or invalid address\n");
+                           }
+                          break;
+#ifdef AZT_PRIVATE_IOCTLS /*not supported by every CDROM driver*/
+              case 'd':   cmd=CDROMREADCOOKED;
+                          printf("Address (min:sec:frame)  ");
+                          scanf("%d:%d:%d",&arg1,&arg2,&arg3);
+                          azt.msf.cdmsf_min0  =arg1;
+                          azt.msf.cdmsf_sec0  =arg2;
+                          azt.msf.cdmsf_frame0=arg3;
+                          if (azt.msf.cdmsf_sec0  > 59) azt.msf.cdmsf_sec0  =59;
+                          if (azt.msf.cdmsf_frame0> 74) azt.msf.cdmsf_frame0=74;
+                          if (ioctl(handle,cmd,&azt.msf)) 
+                           { printf("Drive error, invalid address or unsupported command\n");
+                           }
+                          k=0;
+                          getchar();
+                          for (i=0;i<128;i++)
+                           { printf("%4d:",i*16);
+                             for (j=0;j<16;j++)
+                               { printf("%2x ",azt.buf[i*16+j]);
+                               }
+                             for (j=0;j<16;j++)
+                               { if (isalnum(azt.buf[i*16+j])) 
+                                   printf("%c",azt.buf[i*16+j]);
+                                 else
+                                   printf(".");
+                               }
+                             printf("\n"); 
+                             k++;
+                             if (k>=20)
+                              { printf("press ENTER to continue\n");
+                                getchar();
+                                k=0;
+                              }
+                           } 
+                          break;
+              case 'w':   cmd=CDROMREADRAW;
+                          printf("Address (min:sec:frame)  ");
+                          scanf("%d:%d:%d",&arg1,&arg2,&arg3);
+                          azt.msf.cdmsf_min0  =arg1;
+                          azt.msf.cdmsf_sec0  =arg2;
+                          azt.msf.cdmsf_frame0=arg3;                          
+                          if (azt.msf.cdmsf_sec0  > 59) azt.msf.cdmsf_sec0  =59;
+                          if (azt.msf.cdmsf_frame0> 74) azt.msf.cdmsf_frame0=74;
+                          if (ioctl(handle,cmd,&azt)) 
+                           { printf("Drive error, invalid address or unsupported command\n");
+                           }
+                          k=0;
+                          for (i=0;i<147;i++)
+                           { printf("%4d:",i*16);
+                             for (j=0;j<16;j++)
+                               { printf("%2x ",azt.buf[i*16+j]);
+                               }
+                             for (j=0;j<16;j++)
+                               { if (isalnum(azt.buf[i*16+j])) 
+                                   printf("%c",azt.buf[i*16+j]);
+                                 else
+                                   printf(".");
+                               }
+                             printf("\n"); 
+                             k++;
+                             if (k>=20)
+                              { getchar();
+                                k=0;
+                              }
+                           } 
+                          break;
+#endif
+              case 'v':   cmd=CDROMVOLCTRL;
+                          printf("--Channel 0 Left  (0-255): ");
+                          scanf("%d",&arg1);
+                          printf("--Channel 1 Right (0-255): ");
+                          scanf("%d",&arg2);
+                          volctrl.channel0=arg1;
+                          volctrl.channel1=arg2;
+                          volctrl.channel2=0;
+                          volctrl.channel3=0;
+                          if (ioctl(handle,cmd,&volctrl)) 
+                           { printf("Drive error or unsupported command\n");
+                           }
+                          break;  
+              case 'q':   if (close(handle)) printf("Drive Error: CLOSE\n");
+                          exit(0);
+              case 'h':   help();
+                          break;
+              default:    printf("unknown command\n");
+                          break;
+            }
+       }
+    }
+  return 0;
+}
diff --git a/Documentation/cdrom/cdrom-standard.tex b/Documentation/cdrom/cdrom-standard.tex
new file mode 100644
index 000000000..ba95b97ff
--- /dev/null
+++ b/Documentation/cdrom/cdrom-standard.tex
@@ -0,0 +1,971 @@
+\documentclass{article}
+\def\version{$Id: cdrom-standard.tex,v 1.2 1996/09/22 20:18:00 david Exp $}
+
+\evensidemargin=0pt
+\oddsidemargin=0pt
+\topmargin=-\headheight \advance\topmargin by -\headsep
+\textwidth=15.99cm \textheight=24.62cm % normal A4, 1'' margin
+
+\def\linux{{\sc Linux}}
+\def\cdrom{{\sc CDrom}}
+\def\cdromc{{\tt cdrom.c}}
+\def\cdromh{{\tt cdrom.h}}
+\def\ucdrom{{\tt ucdrom.h}}
+\def\fo{\sl}
+
+\everymath{\it} \everydisplay{\it}
+\catcode `\_=\active \def_{\_\penalty100 }
+\catcode`\<=\active \def<#1>{{\langle\hbox{\rm#1}\rangle}}
+
+\begin{document}
+\title{A \linux\ \cdrom\ standard}
+\author{David van Leeuwen\\{\normalsize\tt david@tm.tno.nl}}
+
+\maketitle
+
+\section{Introduction}
+
+\linux\ is probably the Unix-like operating system that supports the widest
+variety of hardware devices. The reasons for this are presumably
+\begin{itemize}
+\item The large list of different hardware devices available for the popular
+IBM PC-architecture,
+\item The open design of the operating system, such that everybody can
+write a driver for Linux (source code examples).
+\end{itemize}
+The vast choice and openness has lead not only to a wide support of
+hardware devices, but also to a certain divergence in behavior.
+Especially for \cdrom\ devices, the way a particular drive reacts to a
+`standard' $ioctl()$ call varies a lot from one brand to another;
+however, the \linux\ \cdrom\ driver writers kept away from wilderness
+by the practice of evolving a new driver by copying, understanding and
+changing an existing one.
+
+Since the beginning of the \cdrom, many different interfaces
+developed.  Some of them had their own proprietary design (Sony,
+Mitsumi, Panasonic, Philips), other manufacturers adopted an existing
+electrical interface and changed the functionality
+(CreativeLabs/SoundBlaster, Teac, Funai) or simply adapted their
+drives to one or more of the already existing electrical interfaces
+(Aztech, Sanyo, Funai, Vertos, Longshine, Optics Storage and most of
+the `NoName' manufacturers).  In cases where a new drive really
+brought his own interface or used his own command set and flow control
+scheme, either a separate driver had to be written, or an existing
+driver had to get enhanced.
+
+Nowadays, almost all new \cdrom\ types are either ATAPI/IDE or SCSI;
+it is very unlikely that any manufacturer still will create a new
+interface, and new drives for the existing proprietary interfaces are
+getting rare.  But history has delivered us \cdrom\ support for many
+different interfaces.
+
+When (in the 1.3.70's) I looked at the existing interface which is
+expressed through \cdromh\ it appeared to be a rather wild set of
+commands and data formats.\footnote{I cannot recollect what kernel
+  version I looked at, then, presumably 1.2.13 and 1.3.34---the latest
+  kernel that I was indirectly involved in.} It seemed that many
+features of the interface have been added to include certain specific
+capabilities of certain drives, in an {\fo ad hoc\/} manner. More
+importantly, it appeared that actual execution of the commands is
+different for most of the different drivers: e.g., some drivers close
+the tray if an $open()$ call occurs while the tray is unloaded, while
+others do not. Some drivers lock the door upon opening the device, to
+prevent an incoherent file system, but others don't, to allow software
+ejection.  Undoubtedly, the capabilities of the different drives vary,
+but even when two drives have the same capability the driver behavior
+may be different.
+
+I decided to start a discussion on how to improve uniformity,
+addressing all \cdrom-driver developers found in the various driver
+files. The reactions encouraged me to write a uniform (compatible)
+software level \cdromc\ to which this document is the documentation.
+In the mean time, the data structure definitions in \cdromh\ had been
+cleaned up a lot---which was very helpful for the new code.
+ 
+\begin{quote}
+\small
+[Apparently, not all \cdrom\ developers support this initiative.
+They---mainly those who used the already existing drivers not only as
+a coding example, but also as a `user interface' reference during
+their own development---have taken care that \cdromh\ reflects a
+software interface to `user programs' which is unique between all
+drivers as much as possible; these driver writers will continue to
+refine the existing \cdromh\ where it seems necessary, and they tend
+to look if any newly requested functionality isn't already there
+before they are ready to define new structures. The {\tt sbpcd} driver
+gives an example that it is possible to let a robot arm play juke
+box---either with audio or with data CDs---and that it is possible to
+let the juke box work on even if a disk has fallen upon the floor and
+the drive door has closed without having a disk inside; without any
+new software layer or any structures which are not already present in
+\cdromh.  This `other' group of \linux\ \cdrom\ driver writers
+explicitly does {\em not\/} support the idea to define an additional
+software layer between driver and user program.]\parfillskip=0pt
+\end{quote}
+
+The effort (\cdromc) of which this is the documentation is {\em not\/}
+meant to drive a wedge between two groups of driver developers, but
+rather to enable sharing of `strategic code' among drivers. The code
+should {\em not\/} be viewed as a new interface to user-level
+programs, but rather as a new interface between driver code and
+kernel. 
+
+Care is taken that 100\,\% compatibility exists with the data
+structures and programmer's interface defined in \cdromh, and in order
+not to interfere with ongoing development in \cdromh, any `new' data
+structures have been put in a separate header file called \ucdrom.
+Because the data structures of \cdromh\ are fully supported, this
+documentation may also be of help to the programmers using the
+interface defined in \cdromh, but this guide is primarily written to
+help \cdrom\ driver developers adapt their code to use the `common
+\cdrom' code in \cdromc.
+
+Personally, I think that the most important hardware interfaces will
+be the IDE/ATAPI drives and of course the SCSI drives, but as prices
+of hardware drop continuously, it is not unlikely that people will
+have more than one \cdrom\ drive, possibly of mixed types. It is
+important that these drives behave in the same way. (In December 1994,
+one of the cheapest \cdrom\ drives was a Philips cm206, a double-speed
+proprietary drive. In the months that I was busy writing a \linux\ 
+driver for it, proprietary drives became old-fashioned and IDE/ATAPI
+drives became standard. At the time of writing (April 1996) the
+cheapest double speed drive is IDE and at one fifth of the price of
+its predecessor. Eight speed drives are available now.)
+
+This document defines (in pre-release versions: proposes) the various
+$ioctl$s, and the way the drivers should implement this.
+
+\section{Standardizing through another software level}
+\label{cdrom.c}
+
+At the time this document was conceived, all drivers directly implement
+the $ioctl()$ calls through their own routines, with the danger of
+forgetting calls to $verify_area()$ and the risk of divergence in
+implementation. 
+
+For this reason, we\footnote{The writing style is such that `we' is
+used when (at least part of) the \cdrom-device driver authors support
+the idea, an `I' is used for personal opinions} propose to define
+another software-level, that separates the $ioctl()$ and $open()$
+implementation from the actual hardware implementation. Note that we
+do not wish to alter the existing application interface defined in
+\cdromh, but rather want to re-root the hardware-implementation through
+some common code. 
+
+We believe that \cdrom\ drives are specific enough (i.e., different
+from other block-devices such as floppy or hard disc drives), to
+define a set of {\em \cdrom\ device operations},
+$<cdrom-device>_dops$. These are of a different nature than the
+classical block-device file operations $<block-device>_fops$.
+
+The extra interfacing level routines are implemented in a file
+\cdromc, and a low-level \cdrom\ driver hands over the interfacing to
+the kernel by registering the following general $struct\ 
+file_operations$:
+$$
+\halign{$#$\ \hfil&$#$\ \hfil&$/*$ \rm# $*/$\hfil\cr
+struct& file_operations\ cdrom_fops = \{\hidewidth\cr
+        &NULL,                  & lseek \cr
+        &block_read,            & read---general\ block-dev\ read \cr
+        &block_write,           & write---general block-dev write \cr
+        &NULL,                  & readdir \cr
+        &NULL,                  & select \cr
+        &cdrom_ioctl,           & ioctl \cr
+        &NULL,                  & mmap \cr
+        &cdrom_open,            & open \cr
+        &cdrom_release,         & release \cr
+        &NULL,                  & fsync \cr
+        &NULL,                  & fasync \cr
+        &cdrom_media_changed,   & media_change \cr
+        &NULL                   & revalidate \cr
+\};\cr
+}
+$$
+Every active \cdrom\ device shares this $struct$. The routines declared
+above are all implemented in \cdromc, and this is the place where the
+{\em behavior\/} of all \cdrom-devices is defined, and hence
+standardized. The implementation of the interfacing to the various
+types of hardware still is done by the various \cdrom-device drivers,
+but these routines only implement certain {\em capabilities\/} that
+are typical to \cdrom\ (removable-media) devices.
+
+Registration of the \cdrom\ device driver should now be to the general
+routines in \cdromc, not to the VFS any more. The interfacing with
+\cdromc\ is implemented trough two general structures, that contain
+information about the capabilities of the driver, and the specific
+drives on which the driver operates. The structures are seperated to
+contain information about
+\begin{description}
+\item[the low-level driver] It lists the routines that actually
+  implement cdrom operations, and hence the structure is called
+  $cdrom_device_ops$. The structure is conceptually connected to the
+  major number of the device (although some drivers may have have
+  different major numbers, as is the case for the IDE driver).
+\item[the specific drive] It lists the variables informative of the
+  drive that is driven, and hence the structure is called
+  $cdrom_device_info$. The structure is conceptually connected to the
+  minor number of the device.
+\end{description}
+
+The registration is done for each drive found by the driver (and hence
+for each minor number) though the call
+$$register_cdrom(kdev_t\ dev, char * name, 
+  struct\ cdrom_device_info\ <device>_info)
+$$
+This device information structure (described shortly) contains all
+information needed for the kernel to interface with the low-level
+cdrom device driver. One of the main entries of this structure is a
+pointer to the $cdrom_device_ops$ structure of the driver.
+
+This device operations structure lists the implemented routines for
+interfacing to the hardware. [It is impossible to come up with a
+complete list of all capabilities of (future) \cdrom\ drives, as the
+developments in technology follow-up at an incredible rate. Maybe
+write-operation (WORM devices) will become very popular in the
+future.]  The list now is:
+$$
+\halign{$#$\ \hfil&$#$\ \hfil&\hbox to 10em{$#$\hss}&
+  $/*$ \rm# $*/$\hfil\cr
+struct& cdrom_device_ops\ \{ \hidewidth\cr
+  &int& (* open)(struct\ cdrom_device_info *, int)\cr
+  &void& (* release)(struct\ cdrom_device_info *);\cr 
+  &int& (* drive_status)(struct\ cdrom_device_info *);\cr     
+  &int& (* disc_status)(struct\ cdrom_device_info *);\cr      
+  &int& (* media_changed)(struct\ cdrom_device_info *, int);\cr 
+  &int& (* tray_move)(struct\ cdrom_device_info *, int);\cr
+  &int& (* lock_door)(struct\ cdrom_device_info *, int);\cr
+  &int& (* select_speed)(struct\ cdrom_device_info *, int);\cr
+  &int& (* select_disc)(struct\ cdrom_device_info *, int);\cr
+  &int& (* get_last_session) (struct\ cdrom_device_info *, struct\ cdrom_multisession *{});\cr
+  &int& (* get_mcn)(struct\ cdrom_device_info *, struct\ cdrom_mcn *{});\cr
+  &int& (* reset)(struct\ cdrom_device_info *);\cr
+  &int& (* audio_ioctl)(struct\ cdrom_device_info *, unsigned\ int, void *{});\cr 
+  &int& (* dev_ioctl)(struct\ cdrom_device_info *, unsigned\ int, unsigned\ long);\cr
+\noalign{\medskip}
+  &\llap{const\ }int& capability;&  capability flags \cr
+  &int& n_minors;& number of supported minor devices \cr
+}
+$$
+The \cdrom-driver should simply implement (some of) these
+functions, and register the functions to the global \cdrom\ driver,
+which performs interfacing with the Virtual File System and system
+$ioctl$s. The flags $capability$ specify the hardware-capabilities on
+registration of the device. The value $n_minors$ should be a positive
+value indicating the number of minor devices that are supported by the
+driver, normally~1. Although these two variables are `informative'
+rather than `operational,' they are included in $cdrom_device_ops$
+because they describe the cabability of the {\em driver\/} rather than
+the {\em drive}. Nomenclature has always been difficult in computer
+programming. 
+
+Note that most functions have fewer parameters than their
+$blkdev_fops$ counterparts. This is because very little of the
+information in the structures $inode$ and $file$ are used, the main
+parameter is the device $dev$, from which the minor-number can be
+extracted. (Most low-level \cdrom\ drivers don't even look at that value
+as only one device is supported.) This will be available through $dev$
+in $cdrom_device_info$ described below. 
+
+The drive-specific, minor-like information that is registered to
+\cdromc, contains the following fields:
+$$
+\halign{$#$\ \hfil&$#$\ \hfil&\hbox to 10em{$#$\hss}&
+  $/*$ \rm# $*/$\hfil\cr
+struct& cdrom_device_info\ \{ \hidewidth\cr
+  & \llap{$const\ $}struct\ cdrom_device_ops *& ops;& device operations for this major\cr
+  & struct\ cdrom_device_info *& next;& next device_info for this major\cr
+  & void *&  handle;& driver-dependent data\cr
+\noalign{\medskip}
+  & \llap{$const\ $}kdev_t&  dev;& device number (incorporates minor)/\cr
+  & int& mask;& mask of capability: disables them \cr
+  &\llap{$const\ $}int& speed;&  maximum speed for reading data \cr
+  &\llap{$const\ $}int& n_discs;& number of discs in jukebox \cr
+\noalign{\medskip}
+  &int& options : 30;& options flags \cr
+  &long& mc_flags : 2;& media-change buffer flags \cr
+  & int& use_count;& number of times devices is opened\cr
+\}\cr
+}$$
+
+With this $struct$, a linked list of minor devices registrered with
+the same low-level driver is built, though the field $next$.  The
+device number, the device operations struct and specifications of
+properties of the drive are stored in this structure.
+
+The flags $mask$ can be used to mask out some of the capabilities
+listed in $ops\to capability$, if a specific drive doesn't support a
+feature of the driver. The value $speed$ specifies the maximum
+head-rate of the drive, measured in units of normal audio speed
+(176\,kB/sec raw data or 150\,kB/sec filesystem data).  The value
+$n_discs$ should reflect the number of discs the drive can hold
+simultaneously, if it is designed as a juke-box, or otherwise~1.
+The parameters are declared $const$ because they describe properties
+of the drive, which don't change after registration. 
+
+A few registers contain variables local to the \cdrom\ drive. The
+flags $options$ are used to specify how the general \cdrom\ routines
+should behave. These various flags registers should provide enough
+flexibility to adapt to the different user's wishes (and {\em not\/}
+the `arbitrary' wishes of the author of the low-level device driver,
+as is the case in the old scheme). The register $mc_flags$ is used to
+buffer the information from $media_changed()$ to two separate queues.
+Other data that is specific to minor drive, can be accessed through
+$handle$, which can point to a data structure specific to the
+low-level driver. The fields $use_count$, $next$, $options$ and
+$mc_flags$ need not be initialized.
+
+The intermediate software layer that \cdromc\ forms will performs some
+additional bookkeeping. The use count of the device (the number of
+processes that have the device opened) is registered in $use_count$.
+The function $cdrom_ioctl()$ will verify the appropriate user-memory
+regions for read and write, and in case a location on the CD is
+transferred, it will `sanitize' the format by making requests to the
+low-level drivers in a standard format, and translating all formats
+between the user-software and low level drivers. This relieves much of
+the drivers memory checking and format checking and translation. Also,
+the necessary structures will be declared on the program stack.
+
+The implementation of the functions should be as defined in the
+following sections. Two functions {\em must\/} be implemented, namely
+$open()$ and $release()$. Other functions may be omitted, their
+corresponding capability flags will be cleared upon registration.
+Generally, a function returns zero on success and negative on error. A
+function call should return only after the command has completed, but
+of course waiting for the device should not use processor time.
+
+\subsection{$Open(struct\ cdrom_device_info * cdi, int\ purpose)$}
+
+$Open()$ should try to open the device for a specific $purpose$, which
+can be either:
+\begin{itemize}
+\item[0] Open for data read, as is used by {\tt mount()} (2), or the
+user commands {\tt dd} or {\tt cat}.  
+\item[1] Open for $ioctl$ commanding, as is used for audio-CD playing
+programs mostly. 
+\end{itemize}
+In case the driver supports modules, the call $MOD_INC_USE_COUNT$
+should be performed exactly once, if the $open()$ was successful. The
+return value is negative on error, and zero on success. The
+open-for-ioctl call can only fail if there is no hardware.
+
+Notice that any strategic code (closing tray upon $open()$, etc.)\ is
+done by the calling routine in \cdromc, so the low-level routine
+should only be concerned with proper initialization and device-use
+count.
+
+\subsection{$Release(struct\ cdrom_device_info * cdi)$}
+
+In case of module support, a single call $MOD_DEC_USE_COUNT$ should be
+coded here.  Possibly other device-specific actions should be taken
+such as spinning down the device. However, strategic actions such as
+ejection of the tray, or unlocking the door, should be left over to
+the general routine $cdrom_release()$. Also, the invalidation of the
+allocated buffers in the VFS is taken care of by the routine in
+\cdromc.
+
+\subsection{$Drive_status(struct\ cdrom_device_info * cdi)$}
+\label{drive status}
+
+The function $drive_status$, if implemented, should provide
+information of the status of the drive (not the status of the disc,
+which may or may not be in the drive). In \ucdrom\ the possibilities
+are listed: 
+$$
+\halign{$#$\ \hfil&$/*$ \rm# $*/$\hfil\cr
+CDS_NO_INFO& no information available\cr
+CDS_NO_DISC& no disc is inserted, tray is closed\cr
+CDS_TRAY_OPEN& tray is opened\cr
+CDS_DRIVE_NOT_READY& something is wrong, tray is moving?\cr
+CDS_DISC_OK& a disc is loaded and everything is fine\cr
+}
+$$
+%For a juke-box, the second argument $drive_nr$ specifies information
+%is requested for another than the default disc ($drive_nr=0$),
+%possibly only a subset of the return values can be returned.
+
+\subsection{$Disc_status(struct\ cdrom_device_info * cdi)$}
+\label{disc status}
+
+As a complement to $drive_status()$, this function can provide the
+general \cdrom-routines with information about the current disc that
+is inserted in the drive represented by $cdi\to dev$. The history of
+development of the CD's use as a carrier medium for various digital
+information has lead to many different disc types, hence this function
+can return:
+$$
+\halign{$#$\ \hfil&$/*$ \rm# $*/$\hfil\cr
+CDS_NO_INFO& no information available\cr
+CDS_NO_DISC& no disc is inserted, or tray is opened\cr
+CDS_AUDIO& Audio disc (2352 audio bytes/frame)\cr
+CDS_DATA_1& data disc, mode 1 (2048 user bytes/frame)\cr
+CDS_DATA_2& data disc, mode 2 (2336 user bytes/frame)\cr
+CDS_XA_2_1& mixed data (XA), mode 2, form 1 (2048 user bytes)\cr
+CDS_XA_2_2& mixed data (XA), mode 2, form 1 (2324  user bytes)\cr
+}
+$$
+As far as I know, \cdrom s are always of type $CDS_DATA_1$. For
+some information concerning frame layout of the various disc types, see
+a recent version of {\tt cdrom.h}. 
+
+\subsection{$Media_changed(struct\ cdrom_device_info * cdi, int disc_nr)$}
+
+This function is very similar to the original function in $struct\ 
+file_operations$. It returns 1 if the medium of the device $cdi\to
+dev$ has changed since the last call, and 0 otherwise. The parameter
+$disc_nr$ identifies a specific slot in a juke-box, it should be
+ignored for single-disc drives.  Note that by `re-routing' this
+function through $cdrom_media_changed()$, we can implement separate
+queues for the VFS and a new $ioctl()$ function that can report device
+changes to software (e.g., an auto-mounting daemon).
+
+\subsection{$Tray_move(struct\ cdrom_device_info * cdi, int\ position)$}
+
+This function, if implemented, should control the tray movement. (No
+other function should control this.) The parameter $position$ controls
+the desired direction of movement:
+\begin{itemize}
+\item[0] Close tray
+\item[1] Open tray
+\end{itemize}
+This function returns 0 upon success, and a non-zero value upon
+error. Note that if the tray is already in the desired position, no
+action need be taken, and the return value should be 0. 
+
+\subsection{$Lock_door(struct\ cdrom_device_info * cdi, int\ lock)$}
+
+This function (and no other code) controls locking of the door, if the
+drive allows this. The value of $lock$ controls the desired locking
+state:
+\begin{itemize}
+\item[0] Unlock door, manual opening is allowed
+\item[1] Lock door, tray cannot be ejected manually
+\end{itemize}
+Return values are as for $tray_move()$.
+
+\subsection{$Select_speed(struct\ cdrom_device_info * cdi, int\ speed)$}
+
+Although none of the drivers has implemented this function so far,
+some drives are capable of head-speed selection, and hence this is a
+capability that should be standardized through a function in the
+device-operations structure. This function should select the speed at
+which data is read or audio is played back. The special value `0'
+means `auto-selection', i.e., maximum data-rate or real-time audio
+rate. If the drive doesn't have this `auto-selection' capability, the
+decision should be made on the current disc loaded and the return
+value should be positive. A negative return value indicates an
+error. (Although the audio-low-pass filters probably aren't designed
+for it, more than real-time playback of audio might be used for
+high-speed copying of audio tracks). Badly pressed \cdrom s may
+benefit from less-than-maximum head rate.
+
+\subsection{$Select_disc(struct\ cdrom_device_info * cdi, int\ number)$}
+
+If the drive can store multiple discs (a juke-box) this function
+should perform disc selection. It should return the number of the
+selected disc on success, a negative value on error. Currently, only
+the IDE-cd driver supports such functionality.
+
+\subsection{$Get_last_session(struct\ cdrom_device_info * cdi, struct\
+  cdrom_multisession * ms_info)$}
+
+This function should implement the old corresponding $ioctl()$. For
+device $cdi->dev$, the start of the last session of the current disc
+should be returned in the pointer argument $ms_info$. Note that
+routines in \cdromc\ have sanitized this argument: its requested
+format will {\em always\/} be of the type $CDROM_LBA$ (linear block
+addressing mode), whatever the calling software requested. But
+sanitization goes even further: the low-level implementation may
+return the requested information in $CDROM_MSF$ format if it wishes so
+(setting the $ms_info\rightarrow addr_format$ field appropriately, of
+course) and the routines in \cdromc\ will make the transform if
+necessary. The return value is 0 upon success.
+
+\subsection{$Get_mcn(struct\ cdrom_device_info * cdi, struct\
+  cdrom_mcn * mcn)$}
+
+Some discs carry a `Media Catalog Number' (MCN), also called
+`Universal Product Code' (UPC). This number should reflect the number
+that is generally found in the bar-code on the product. Unfortunately,
+the few discs that carry such a number on the disc don't even use the
+same format. The return argument to this function is a pointer to a
+pre-declared memory region of type $struct\ cdrom_mcn$. The MCN is
+expected as a 13-character string, terminated by a null-character.
+
+\subsection{$Reset(struct\ cdrom_device_info * cdi)$}
+
+This call should implement hard-resetting the drive (although in
+circumstances that a hard-reset is necessary, a drive may very well
+not listen to commands anymore). Preferably, control is returned to the
+caller only after the drive has finished resetting.
+
+\subsection{$Audio_ioctl(struct\ cdrom_device_info * cdi, unsigned\
+  int\ cmd, void * arg)$}
+
+Some of the \cdrom-$ioctl$s defined in {\tt cdrom.h} can be
+implemented by the routines described above, and hence the function
+$cdrom_ioctl$ will use those. However, most $ioctl$s deal with
+audio-control. We have decided to leave these accessed through a
+single function, repeating the arguments $cmd$ and $arg$. Note that
+the latter is of type $void*{}$, rather than $unsigned\ long\
+int$. The routine $cdrom_ioctl()$ does do some useful things,
+though. It sanitizes the address format type to $CDROM_MSF$ (Minutes,
+Seconds, Frames) for all audio calls. It also verifies the memory
+location of $arg$, and reserves stack-memory for the argument. This
+makes implementation of the $audio_ioctl()$ much simpler than in the
+old driver scheme. For an example you may look up the function
+$cm206_audio_ioctl()$ in {\tt cm206.c} that should be updated with
+this documentation. 
+
+An unimplemented ioctl should return $-EINVAL$, but a harmless request
+(e.g., $CDROMSTART$) may be ignored by returning 0 (success). Other
+errors should be according to the standards, whatever they are. (We
+may decide to sanitize the return value in $cdrom_ioctl()$, in order
+to guarantee a uniform interface to the audio-player software.)
+
+\subsection{$Dev_ioctl(struct\ cdrom_device_info * cdi, unsigned\ int\
+  cmd, unsigned\ long\ arg)$}
+
+Some $ioctl$s seem to be specific to certain \cdrom\ drives. That is,
+they are introduced to service some capabilities of certain drives. In
+fact, there are 6 different $ioctl$s for reading data, either in some
+particular kind of format, or audio data. Not many drives support
+reading audio tracks as data, I believe this is because of protection
+of copyrights of artists. Moreover, I think that if audio-tracks are
+supported, it should be done through the VFS and not via $ioctl$s. A
+problem here could be the fact that audio-frames are 2352 bytes long,
+so either the audio-file-system should ask for 75264 bytes at once
+(the least common multiple of 512 and 2352), or the drivers should
+bend their backs to cope with this incoherence (to which I would be
+opposed). Once this question is resolved, this code should be
+standardized in \cdromc.
+
+Because there are so many $ioctl$s that seem to be introduced to
+satisfy certain drivers,\footnote{Is there software around that
+  actually uses these? I'd be interested!} any `non-standard' $ioctl$s
+are routed through the call $dev_ioctl()$. In principle, `private'
+$ioctl$s should be numbered after the device's major number, and not
+the general \cdrom\ $ioctl$ number, {\tt 0x53}. Currently the
+non-supported $ioctl$s are: {\it CDROMREADMODE1, CDROMREADMODE2,
+  CDROMREADAUDIO, CDROMREADRAW, CDROMREADCOOKED, CDROMSEEK,
+  CDROMPLAY\-BLK and CDROMREADALL}.
+
+\subsection{\cdrom\ capabilities}
+
+Instead of just implementing some $ioctl$ calls, the interface in
+\cdromc\ supplies the possibility to indicate the {\em capabilities\/}
+of a \cdrom\ drive. This can be done by ORing any number of
+capability-constants that are defined in \ucdrom\ at the registration
+phase. Currently, the capabilities are any of:
+$$
+\halign{$#$\ \hfil&$/*$ \rm# $*/$\hfil\cr
+CDC_CLOSE_TRAY& can close tray by software control\cr
+CDC_OPEN_TRAY& can open tray\cr
+CDC_LOCK& can lock and unlock the door\cr
+CDC_SELECT_SPEED& can select speed, in units of $\sim$150\,kB/s\cr
+CDC_SELECT_DISC& drive is juke-box\cr
+CDC_MULTI_SESSION& can read sessions $>\rm1$\cr
+CDC_MCN& can read Medium Catalog Number\cr
+CDC_MEDIA_CHANGED& can report if disc has changed\cr
+CDC_PLAY_AUDIO& can perform audio-functions (play, pause, etc)\cr
+}
+$$
+The capability flag is declared $const$, to prevent drivers from
+accidentally tampering with the contents. The capability fags actually
+inform \cdromc\ on what the driver is capable of. If the drive found
+by the driver does not have the capability, is can be masked out by
+the $cdrom_device_info$ variable $mask$. For instance, the SCSI cdrom
+driver has implemeted the code for loading and ejecting cdrom's, and
+hence its corresponding flags in $capability$ will be set. But a SCSI
+cdrom drive might be a caddy system, which can't load the tray, and
+hence for this drive the $cdrom_device_info$ struct will have set
+the $CDC_CLOSE_TRAY$ bit in $mask$.
+
+In the file \cdromc\ you will encounter many constructions of the type
+$$\it
+if\ (cdo\rightarrow capability \mathrel\& \mathord{\sim} cdi\rightarrow mask 
+   \mathrel{\&} CDC_<capability>) \ldots
+$$
+There is no $ioctl$ to set the mask\dots The reason is that
+I think it is better to control the {\em behavior\/} rather than the
+{\em capabilities}.
+
+\subsection{Options}
+
+A final flag register controls the {\em behavior\/} of the \cdrom\
+drives, in order to satisfy different users' wishes, hopefully
+independently of the ideas of the respective author who happened to
+have made the drive's support available to the \linux\ community. The
+current behavior options are:
+$$
+\halign{$#$\ \hfil&$/*$ \rm# $*/$\hfil\cr
+CDO_AUTO_CLOSE& try to close tray upon device $open()$\cr
+CDO_AUTO_EJECT& try to open tray on last device $close()$\cr
+CDO_USE_FFLAGS& use $file_pointer\rightarrow f_flags$ to indicate
+ purpose for $open()$\cr
+CDO_LOCK& try to lock door if device is opened\cr
+CDO_CHECK_TYPE& ensure disc type is data if opened for data\cr
+}
+$$
+
+The initial value of this register is $CDO_AUTO_CLOSE \mathrel|
+CDO_USE_FFLAGS \mathrel| CDO_LOCK$, reflecting my own view on user
+interface and software standards. Before you protest, there are two
+new $ioctl$s implemented in \cdromc, that allow you to control the
+behavior by software. These are:
+$$
+\halign{$#$\ \hfil&$/*$ \rm# $*/$\hfil\cr
+CDROM_SET_OPTIONS& set options specified in $(int)\ arg$\cr
+CDROM_CLEAR_OPTIONS& clear options specified in $(int)\ arg$\cr
+}
+$$
+One option needs some more explanation: $CDO_USE_FFLAGS$. In the next
+section we explain what the need for this option is.
+
+\section{The need to know the purpose of opening}
+
+Traditionally, Unix devices can be used in two different `modes',
+either by reading/writing to the device file, or by issuing
+controlling commands to the device, by the device's $ioctl()$
+call. The problem with \cdrom\ drives, is that they can be used for
+two entirely different purposes. One is to mount removable
+file systems, \cdrom s, the other is to play audio CD's. Audio commands
+are implemented entirely through $ioctl$s, presumably because the
+first implementation (SUN?) has been such. In principle there is
+nothing wrong with this, but a good control of the `CD player' demands
+that the device can {\em always\/} be opened in order to give the
+$ioctl$ commands, regardless of the state the drive is in. 
+
+On the other hand, when used as a removable-media disc drive (what the
+original purpose of \cdrom s is) we would like to make sure that the
+disc drive is ready for operation upon opening the device. In the old
+scheme, some \cdrom\ drivers don't do any integrity checking, resulting
+in a number of i/o errors reported by the VFS to the kernel when an
+attempt for mounting a \cdrom\ on an empty drive occurs. This is not a
+particularly elegant way to find out that there is no \cdrom\ inserted;
+it more-or-less looks like the old IBM-PC trying to read an empty floppy
+drive for a couple of seconds, after which the system complains it
+can't read from it. Nowadays we can {\em sense\/} the existence of a
+removable medium in a drive, and we believe we should exploit that
+fact. An integrity check on opening of the device, that verifies the
+availability of a \cdrom\ and its correct type (data), would be
+desirable.
+
+These two ways of using a \cdrom\ drive, principally for data and
+secondarily for playing audio discs, have different demands for the
+behavior of the $open()$ call. Audio use simply wants to open the
+device in order to get a file handle which is needed for issuing
+$ioctl$ commands, while data use wants to open for correct and
+reliable data transfer. The only way user programs can indicate what
+their {\em purpose\/} of opening the device is, is through the $flags$
+parameter (see {\tt open(2)}). For \cdrom\ devices, these flags aren't
+implemented (some drivers implement checking for write-related flags,
+but this is not strictly necessary if the device file has correct
+permission flags). Most option flags simply don't make sense to
+\cdrom\ devices: $O_CREAT$, $O_NOCTTY$, $O_TRUNC$, $O_APPEND$, and
+$O_SYNC$ have no meaning to a \cdrom. 
+
+We therefore propose to use the flag $O_NONBLOCK$ to indicate
+that the device is opened just for issuing $ioctl$
+commands. Strictly, the meaning of $O_NONBLOCK$ is that opening and
+subsequent calls to the device don't cause the calling process to
+wait. We could interpret this as ``don't wait until someone has
+inserted some valid data-\cdrom.'' Thus, our proposal of the
+implementation for the $open()$ call for \cdrom s is:
+\begin{itemize}
+\item If no other flags are set than $O_RDONLY$, the device is opened
+for data transfer, and the return value will be 0 only upon successful
+initialization of the transfer. The call may even induce some actions
+on the \cdrom, such as closing the tray.  
+\item If the option flag $O_NONBLOCK$ is set, opening will always be
+successful, unless the whole device doesn't exist. The drive will take
+no actions whatsoever. 
+\end{itemize}
+
+\subsection{And what about standards?}
+
+You might hesitate to accept this proposal as it comes from the
+\linux\ community, and not from some standardizing institute. What
+about SUN, SGI, HP and all those other Unix and hardware vendors?
+Well, these companies are in the lucky position that they generally
+control both the hardware and software of their supported products,
+and are large enough to set their own standard. They do not have to
+deal with a dozen or more different, competing hardware
+configurations.\footnote{Personally, I think that SUN's approach to
+mounting \cdrom s is very good in origin: under Solaris a
+volume-daemon automatically mounts a newly inserted \cdrom\ under {\tt
+/cdrom/$<volume-name>$/}. In my opinion they should have pushed this
+further and have {\em every\/} \cdrom\ on the local area network be
+mounted at the similar location, i.e., no matter in which particular
+machine you insert a \cdrom, it will always appear at the same
+position in the directory tree, on every system. When I wanted to
+implement such a user-program for \linux, I came across the
+differences in behavior of the various drivers, and the need for an
+$ioctl$ informing about media changes.}
+
+We believe that using $O_NONBLOCK$ to indicate that a device is being opened
+for $ioctl$ commands only can be easily introduced in the \linux\
+community. All the CD-player authors will have to be informed, we can
+even send in our own patches to the programs. The use of $O_NONBLOCK$
+has most likely no influence on the behavior of the CD-players on
+other operating systems than \linux. Finally, a user can always revert
+to old behavior by a call to $ioctl(file_descriptor, CDROM_CLEAR_OPTIONS,
+CDO_USE_FFLAGS)$. 
+
+\subsection{The preferred strategy of $open()$}
+
+The routines in \cdromc\ are designed in such a way that a run-time
+configuration of the behavior of \cdrom\ devices (of {\em any\/} type)
+can be carried out, by the $CDROM_SET/CLEAR_OPTIONS$ $ioctls$. Thus, various
+modes of operation can be set:
+\begin{description}
+\item[$CDO_AUTO_CLOSE \mathrel| CDO_USE_FFLAGS \mathrel| CDO_LOCK$]
+This is the default setting. (With $CDO_CHECK_TYPE$ it will be better,
+in the future.) If the device is not yet opened by any other process,
+and it is opened for data ($O_NONBLOCK$ is not set) and the tray is
+found open, an attempt to close the tray is made. Then, it is verified
+that a disc is in the drive and, if $CDO_CHECK_TYPE$ is set, that its
+type is `data mode 1.' Only if all tests are passed, the return value
+is zero. The door is locked to prevent file system corruption. If
+opened for audio ($O_NONBLOCK$ is set), no actions are taken and a
+value of 0 will be returned.
+\item[0] $Open()$ will always be successful, the option flags are
+ignored. Neither actions are undertaken, nor any integrity checks are
+made. 
+\item[$CDO_AUTO_CLOSE \mathrel| CDO_AUTO_EJECT \mathrel| CDO_LOCK$]
+This mimics the behavior of the current sbpcd-driver. The option flags
+are ignored, the tray is closed on the first open, if
+necessary. Similarly, the tray is opened on the last release, i.e., if
+a \cdrom\ is unmounted, it is automatically ejected, such that the
+user can replace it. 
+\end{description}
+We hope that these option can convince everybody (both driver
+maintainers and user program developers) to adapt to the new \cdrom\
+driver scheme and option flag interpretation. 
+
+\section{Description of routines in \cdromc}
+
+Only a few routines in \cdromc\ are exported to the drivers. In this
+section we will treat these, as well as the functioning of the routines
+that `take over' the interface to the kernel. The header file
+belonging to \cdromc\ is called \ucdrom, but may be included in {\tt
+cdrom.h} in the future.
+
+\subsection{$struct\ file_operations\ cdrom_fops$}
+
+The contents of this structure has been described in
+section~\ref{cdrom.c}, and this structure should be used in
+registering the block device to the kernel:
+$$
+register_blkdev(major, <name>, \&cdrom_fops);
+$$
+
+\subsection{$Int\ register_cdrom(kdev_t\ dev, char * name, struct\
+cdrom_device_info\ * cdi)$}
+
+Similar to registering $cdrom_fops$ to the kernel, the device
+operations and information structures, as described in
+section~\ref{cdrom.c}, should be registered to the general \cdrom\ 
+interface:
+$$
+register_cdrom(dev, <name>, \&<device>_info);
+$$
+This function returns zero upon success, and non-zero upon
+failure. The structure $<device>_info$ should have a pointer the
+driver's $<device>_dops$, as in 
+$$
+\vbox{\halign{&$#$\hfil\cr
+struct\ &cdrom_device_info\ <device>_info = \{\cr
+& <device>_dops;\cr
+&\ldots\cr
+\}\cr
+}}$$
+Note that a drivers has one static structure, $<device>_dops$, while
+it has as many structures $<device>_info$ as there are minor devices
+active. $Register_cdrom()$ builds a linked list from these. 
+
+\subsection{$Int\ unregister_cdrom(struct\ cdrom_device_info * cdi)$}
+
+Unregistering device $cdi$ with minor number $MINOR(cdi\to dev)$
+removes the minor device from the list. If it was the last minor for
+the driver, this disconnects the registered device-operation routines
+from the \cdrom\ interface. This function returns zero upon success,
+and non-zero upon failure.
+
+\subsection{$Int\ cdrom_open(struct\ inode * ip, struct\ file * fp)$}
+
+This function is not called directly by the low-level drivers, it is
+listed in the standard $cdrom_fops$. If the VFS opens a file, this
+function becomes active. A strategy logic is implemented in this
+routine, taking care of all capabilities and options that are set in
+the $cdrom_device_ops$ connected to the device. Then, the program flow is
+transferred to the device_dependent $open()$ call. 
+
+\subsection{$Void\ cdrom_release(struct\ inode *ip, struct\ file
+*fp)$}
+
+This function implements the reverse-logic of $cdrom_open()$, and then
+calls the device-dependent $release()$ routine.  When the use-count
+has reached 0, the allocated buffers in the are flushed by calls to
+$sync_dev(dev)$ and $invalidate_buffers(dev)$.
+
+
+\subsection{$Int\ cdrom_ioctl(struct\ inode *ip, struct\ file *fp,
+                       unsigned\ int\ cmd, unsigned\ long\ arg)$}
+\label{cdrom-ioctl}
+
+This function handles all $ioctl$ requests for \cdrom\ devices in a
+uniform way. The different calls fall into three categories: $ioctl$s
+that can be directly implemented by device operations, ones that are
+routed through the call $audio_ioctl()$, and the remaining ones, that
+are presumable device-dependent. Generally, a negative return value
+indicates an error. 
+
+\subsubsection{Directly implemented $ioctl$s}
+\label{ioctl-direct}
+
+The following `old' \cdrom-$ioctl$s are implemented by directly
+calling device-operations in $cdrom_device_ops$, if implemented and
+not masked:
+\begin{description}
+\item[CDROMMULTISESSION] Requests the last session on a \cdrom.
+\item[CDROMEJECT] Open tray. 
+\item[CDROMCLOSETRAY] Close tray.
+\item[CDROMEJECT_SW] If $arg\not=0$, set behavior to auto-close (close
+tray on first open) and auto-eject (eject on last release), otherwise
+set behavior to non-moving on $open()$ and $release()$ calls.
+\item[CDROM_GET_MCN or CDROM_GET_UPC] Get the Medium Catalog Number from a CD.
+\end{description}
+
+\subsubsection{$Ioctl$s rooted through $audio_ioctl()$}
+\label{ioctl-audio}
+
+The following set of $ioctl$s are all implemented through a call to
+the $cdrom_fops$ function $audio_ioctl()$. Memory checks and
+allocation are performed in $cdrom_ioctl()$, and also sanitization of
+address format ($CDROM_LBA$/$CDROM_MSF$) is done.
+\begin{description}
+\item[CDROMSUBCHNL] Get sub-channel data in argument $arg$ of type $struct\
+cdrom_subchnl *{}$.
+\item[CDROMREADTOCHDR] Read Table of Contents header, in $arg$ of type
+$struct\ cdrom_tochdr *{}$. 
+\item[CDROMREADTOCENTRY] Read a Table of Contents entry in $arg$ and
+specified by $arg$ of type $struct\ cdrom_tocentry *{}$.
+\item[CDROMPLAYMSF] Play audio fragment specified in Minute, Second,
+Frame format, delimited by $arg$ of type $struct\ cdrom_msf *{}$.
+\item[CDROMPLAYTRKIND] Play audio fragment in track-index format
+delimited by $arg$ of type $struct\ cdrom_ti *{}$.
+\item[CDROMVOLCTRL] Set volume specified by $arg$ of type $struct\
+cdrom_volctrl *{}$.
+\item[CDROMVOLREAD] Read volume into by $arg$ of type $struct\
+cdrom_volctrl *{}$.
+\item[CDROMSTART] Spin up disc.
+\item[CDROMSTOP] Stop playback of audio fragment.
+\item[CDROMPAUSE] Pause playback of audio fragment.
+\item[CDROMRESUME] Resume playing.
+\end{description}
+
+\subsubsection{New $ioctl$s in \cdromc}
+
+The following $ioctl$s have been introduced to allow user programs to
+control the behavior of individual \cdrom\ devices. New $ioctl$
+commands can be identified by the underscores in their names.
+\begin{description}
+\item[CDROM_SET_OPTIONS] Set options specified by $arg$. Returns the
+option flag register after modification. Use  $arg = \rm0$ for reading
+the current flags.
+\item[CDROM_CLEAR_OPTIONS] Clear options specified by $arg$. Returns
+  the option flag register after modification.
+\item[CDROM_SELECT_SPEED] Select head-rate speed of disc specified as
+  by $arg$. The value 0 means `auto-select', i.e., play audio discs at
+  real time and data disc at maximum speed. The value $arg$ is
+  checked against the maximum head rate of the drive found in
+  the $cdrom_dops$.
+\item[CDROM_SELECT_DISC] Select disc numbered $arg$ from a juke-box.
+  First disc is numbered 0. The number $arg$ is checked against the
+  maximum number of discs in the juke-box found in the $cdrom_dops$.
+\item[CDROM_MEDIA_CHANGED] Returns 1 if a disc has been changed since
+  the last call. Note that calls to $cdrom_media_changed$ by the VFS
+  are treated by an independent queue, so both mechanisms will detect
+  a media change once. Currently, \cdromc\ implements maximum 16 minors
+  per major device.
+\item[CDROM_DRIVE_STATUS] Returns the status of the drive by a call to
+  $drive_status()$. Return values are as defined in section~\ref{drive
+    status}. Note that this call doesn't return information on the
+  current playing activity of the drive; this can be polled through an
+  $ioctl$ call to $CDROMSUBCHNL$.
+\item[CDROM_DISC_STATUS] Returns the type of the disc currently in the
+  drive by a call to $disc_status()$. Return values are as defined in
+  section~\ref{disc status}.
+\end{description}
+
+\subsubsection{Device dependent $ioct$s}
+
+Finally, all other $ioctl$s are passed to the function $dev_ioctl()$,
+if implemented. No memory allocation or verification is carried out. 
+
+\subsection{How to update your driver}
+
+\begin{enumerate}
+\item Make a backup of your current driver. 
+\item Get hold of the files \cdromc\ and \ucdrom, they should be in
+the directory tree that came with this documentation. 
+\item Include {\tt \char`\<linux/ucdrom.h>} just after {\tt cdrom.h}.
+\item Change the 3rd argument of $register_blkdev$ from
+$\&<your-drive>_fops$ to $\&cdrom_fops$. 
+\item Just after that line, add a line to register to the \cdrom\
+routines: 
+$$register_cdrom(major, <name>, <your-drive>_dops);$$
+Similarly, add a call to $unregister_cdrom()$. 
+\item Copy an example of the device-operations $struct$ to your source,
+e.g., from {\tt cm206.c} $cm206_dops$, and change all entries to names
+corresponding to your driver, or names you just happen to like. If
+your driver doesn't support a certain function, make the entry
+$NULL$. At the entry $capability$ you should list all capabilities
+your drive could support, in principle. If your drive has a capability
+that is not listed, please send me a message.
+\item Implement all functions in your $<device>_dops$ structure,
+according to prototypes listed in \ucdrom, and specifications given in
+section~\ref{cdrom.c}. Most likely you have already implemented
+the code in a large part, and you may just have to adapt the prototype
+and return values. 
+\item Rename your $<device>_ioctl()$ function to $audio_ioctl$ and
+change the prototype a little. Remove entries listed in the first part
+in section~\ref{cdrom-ioctl}, if your code was OK, these are just calls
+to the routines you adapted in the previous step. 
+\item You may remove all remaining memory checking code in the
+$audio_ioctl()$ function that deals with audio commands (these are
+listed in the second part of section~\ref{cdrom-ioctl}). There is no
+need for memory allocation either, so most $case$s in the $switch$
+statement look similar to:
+$$
+case\ CDROMREADTOCENTRY\colon
+get_toc_entry\bigl((struct\ cdrom_tocentry *{})\ arg\bigr);
+$$
+\item All remaining $ioctl$ cases must be moved to a separate
+function, $<device>_ioctl$, the device-dependent $ioctl$s. Note that
+memory checking and allocation must be kept in this code!
+\item Change the prototypes of $<device>_open()$ and
+$<device>_release()$, and remove any strategic code (i.e., tray
+movement, door locking, etc.). 
+\item Try to recompile the drivers. We advice you to use modules, both
+for {\tt cdrom.o} and your driver, as debugging is much easier this
+way.
+\end{enumerate} 
+
+\section{Thanks}
+
+Thanks to all the people involved. Thanks to Scott Snyder and Gerd
+Knorr, who were the first to implement this interface for SCSI and
+IDE-CD drivers and added many ideas for extension of the data
+structures relative to kernel~2.0. Further thanks to Thomas Quinot,
+Jon Tombs, Ken Pizzini, Eberhard M\"onkeberg and Andrew Kroll, the
+\linux\ \cdrom\ device driver developers who were kind enough to give
+suggestions and criticisms during the writing. Finally of course, I
+want to thank Linus Torvalds for making this possible in the first
+place.
+
+\vfill
+$\version$
+\eject
+\end{document}
+
diff --git a/Documentation/cdrom/cdu31a b/Documentation/cdrom/cdu31a
new file mode 100644
index 000000000..6fa1d4b0f
--- /dev/null
+++ b/Documentation/cdrom/cdu31a
@@ -0,0 +1,196 @@
+
+		CDU31A/CDU33A Driver Info
+		-------------------------
+
+Information on the Sony CDU31A/CDU33A CDROM driver for the Linux
+kernel.
+
+   Corey Minyard (minyard@metronet.com)
+  
+   Colossians 3:17
+
+Crude Table of Contents
+-----------------------
+
+  Setting Up the Hardware
+  Configuring the Kernel
+  Configuring as a Module
+  Driver Special Features
+
+  
+This device driver handles Sony CDU31A/CDU33A CDROM drives and
+provides a complete block-level interface as well as an ioctl()
+interface as specified in include/linux/cdrom.h).  With this
+interface, CDROMs can be accessed, standard audio CDs can be played
+back normally, and CD audio information can be read off the drive.
+
+Note that this will only work for CDU31A/CDU33A drives.  Some vendors
+market their drives as CDU31A compatible.  They lie.  Their drives are
+really CDU31A hardware interface compatible (they can plug into the
+same card).  They are not software compatible.
+
+Setting Up the Hardware
+-----------------------
+
+The CDU31A driver in unable to safely tell if an interface card is
+present that it can use because the interface card does not announce
+its presence in any way besides placing 4 I/O locations in memory.  It
+used to just probe memory and attempt commands, but Linus wisely asked
+me to remove that because it could really screw up other hardware in
+the system.
+
+Because of this, you must tell the kernel where the drive interface
+is, what interrupts are used, and possibly if you are on a PAS-16
+soundcard.
+
+If you have the Sony CDU31A/CDU33A drive interface card, the following
+diagram will help you set it up.  If You have another card, you are on
+your own.  You need to make sure that the I/O address and interrupt is
+not used by another card in the system.  You will need to know the I/O
+address and interrupt you have set.  Note that use of interrupts is
+highly recommended, if possible, it really cuts down on CPU used.
+Unfortunately, most soundcards do not support interrupts for their
+CDROM interfaces.  By default, the Sony interface card comes with
+interrupts disabled.
+   
+        +----------+-----------------+----------------------+
+        |  JP1     |  34 Pin Conn    |                      |
+        |  JP2     +-----------------+                      |
+        |  JP3                                              |
+        |  JP4                                              |
+        |                                                   +--+
+        |                                                   |  +-+
+        |                                                   |  | |  External
+        |                                                   |  | |  Connector
+        |                                                   |  | |
+        |                                                   |  +-+
+        |                                                   +--+
+        |                                                   |
+        |                                          +--------+
+        |                                          |
+        +------------------------------------------+
+   
+      JP1 sets the Base Address, using the following settings:
+   
+        Address         Pin 1           Pin 2
+        -------         -----           -----
+        0x320           Short           Short
+        0x330           Short           Open
+        0x340           Open            Short
+        0x360           Open            Open
+   
+      JP2 and JP3 configure the DMA channel; they must be set the same.
+   
+        DMA             Pin 1           Pin 2           Pin 3
+        ---             -----           -----           -----
+        1               On              Off             On
+        2               Off             On              Off
+        3               Off             Off             On
+   
+      JP4 Configures the IRQ:
+   
+        IRQ     Pin 1           Pin 2           Pin 3           Pin 4
+        ---     -----           -----           -----           -----
+        3       Off             Off             On              Off
+        4       Off             Off*            Off             On
+        5       On              Off             Off             Off
+        6       Off             On              Off             Off
+   
+                  The documentation states to set this for interrupt
+                  4, but I think that is a mistake.
+
+Note that if you have another interface card, you will need to look at
+the documentation to find the I/O base address.  This is specified to
+the SLCD.SYS driver for DOS with the /B: parameter, so you can look at
+you DOS driver setup to find the address, if necessary.
+
+Configuring the Kernel
+----------------------
+
+You must tell the kernel where the drive is at boot time.  This can be
+done at the Linux boot prompt, by using LILO, or by using Bootlin.
+Note that this is no substitute for HOWTOs and LILO documentation, if
+you are confused please read those for info on bootline configuration
+and LILO.
+
+At the linux boot prompt, press the ALT key and add the following line
+after the boot name (you can let the kernel boot, it will tell you the
+default boot name while booting):
+
+	cdu31a=<base address>,<interrupt>[,PAS]
+
+The base address needs to have "0x" in front of it, since it is in
+hex.  For instance, to configure a drive at address 320 on interrupt 5,
+use the following:
+
+	cdu31a=0x320,5
+
+I use the following boot line:
+
+	cdu31a=0x1f88,0,PAS
+
+because I have a PAS-16 which does not support interrupt for the
+CDU31A interface.
+
+Adding this as an append line at the beginning of the /etc/lilo.conf
+file will set it for lilo configurations.  I have the following as the
+first line in my lilo.conf file:
+
+	append="cdu31a=0x1f88,0"
+
+I'm not sure how to set up Bootlin (I have never used it), if someone
+would like to fill in this section please do.
+
+
+Configuring as a Module
+-----------------------
+
+The driver supports loading as a module.  However, you must specify
+the boot address and interrupt on the boot line to insmod.  You can't
+use modprobe to load it, since modprobe doesn't support setting
+variables.
+
+Anyway, I use the following line to load my driver as a module
+
+  /sbin/insmod /lib/modules/`uname -r`/misc/cdu31a.o cdu31a_port=0x1f88
+
+You can set the following variables in the driver:
+
+  cdu31a_port=<I/O address> - sets the base I/O.  If hex, put 0x in
+			      front of it.  This must be specified.
+
+  cdu31a_irq=<interrupt> - Sets the interrupt number.  Leaving this
+			   off will turn interrupts off.
+
+
+Driver Special Features
+-----------------------
+
+This section describes features beyond the normal audio and CD-ROM
+functions of the drive.
+
+2048 byte buffer mode
+
+If a disk is mounted with -o block=2048, data is copied straight from
+the drive data port to the buffer.  Otherwise, the readahead buffer
+must be involved to hold the other 1K of data when a 1K block
+operation is done.  Note that with 2048 byte blocks you cannot execute
+files from the CD.
+
+XA compatibility
+
+The driver should support XA disks for both the CDU31A and CDU33A.  It
+does this transparently, the using program doesn't need to set it.
+
+Multi-Session
+
+A multi-session disk looks just like a normal disk to the user.  Just
+mount one normally, and all the data should be there.  A special
+thanks to Koen for help with this!
+
+Raw sector I/O
+
+Using the CDROMREADAUDIO it is possible to read raw audio and data
+tracks.  Both operations return 2352 bytes per sector.  On the data
+tracks, the first 12 bytes is not returned by the drive and the value
+of that data is indeterminate.
diff --git a/Documentation/cdrom/cm206 b/Documentation/cdrom/cm206
new file mode 100644
index 000000000..9cbbdcd76
--- /dev/null
+++ b/Documentation/cdrom/cm206
@@ -0,0 +1,185 @@
+This is the readme file for the driver for the Philips/LMS cdrom drive
+cm206 in combination with the cm260 host adapter card. 
+
+				(c) 1995 David A. van Leeuwen
+   
+Changes since version 0.99
+--------------------------
+- Interfacing to the kernel is routed though an extra interface layer, 
+  cdrom.c. This allows runtime-configurable `behavior' of the cdrom-drive, 
+  independent of the driver. 
+
+Features since version 0.33
+---------------------------
+- Full audio support, that is, both  workman, workbone and cdp work
+  now reasonably. Reading TOC still takes some time. xmcd has been
+  reported to run successfully. 
+- Made auto-probe code a little better, i hope
+
+Features since version 0.28
+---------------------------
+- Full speed transfer rate (300 kB/s).
+- Minimum kernel memory usage for buffering (less than 3 kB).
+- Multisession support.
+- Tray locking.
+- Statistics of driver accessible to the user.
+- Module support.
+- Auto-probing of adapter card's base port and irq line,
+  also configurable at boot time or module load time.
+
+
+Decide how you are going to use the driver. There are two
+options:
+
+   (a) installing the driver as a resident part of the kernel
+   (b) compiling the driver as a loadable module
+
+   Further, you must decide if you are going to specify the base port
+   address and the interrupt request line of the adapter card cm260 as
+   boot options for (a), module parameters for (b), use automatic
+   probing of these values, or hard-wire your adaptor cards settings
+   into the source code. If you don't care, you can choose for
+   autoprobing, which is the default. In that case you can move on to
+   the next step.
+
+Compiling the kernel
+--------------------
+1) move to /usr/src/linux and do a 
+
+	make config
+
+   If you have chosen for option (a), answer yes to CONFIG_CM206 and
+   CONFIG_ISO9660_FS.
+
+   If you have chosen for option (b), answer yes to CONFIG_MODVERSIONS
+   and no (!) to CONFIG_CM206 and CONFIG_ISO9660_FS. 
+
+2) then do a 
+	
+	make dep; make clean; make zImage; make modules
+
+3) do the usual things to install a new image (backup the old one, run
+   `rdev -R zImage 1', copy the new image in place, run lilo).  Might
+   be `make zlilo'.
+
+Using the driver as a module
+----------------------------
+If you will only seldomly use the cd-rom driver, you can choose for
+option (b), install as a loadable module. You may have to re-compile
+the module when you upgrade the kernel to a new version. 
+
+Since version 0.96, much of the functionality has been transferred to
+a generic cdrom interface in the file cdrom.c. The module cm206.o
+depends on cdrom.o. If the latter is not compiled into the kernel,
+you must explicitly load it before cm206.o:
+
+	 insmod /usr/src/linux/modules/cdrom.o
+
+To install the module, you use the command, as root
+
+	insmod /usr/src/linux/modules/cm206.o
+
+You can specify the base address on the command line as well as the irq 
+line to be used, e.g.
+
+	insmod /usr/src/linux/modules/cm206.o cm206=0x300,11
+
+The order of base port and irq line doesn't matter; you may specify only
+one, the other will have the value of the compiled-in default.  You
+may also have to install the file-system module `iso9660.o', if you
+didn't compile that into the kernel. 
+
+
+Using the driver as part of the kernel
+--------------------------------------
+If you have chosen for option a, you can specify the base-port
+address and irq on the lilo boot command line, e.g.:
+
+	LILO: linux cm206=0x340,11
+
+This assumes that your linux kernel image keyword is `linux'. 
+If you may specify either IRQ (3--11) or base port (0x300--0x370),
+auto probing is turned off for both settings, thus setting the 
+other value to the compiled-in default.
+
+Note that you can put these parameters also in the lilo configuration file:
+
+# linux config
+image = /vmlinuz
+   root = /dev/hda1
+   label = Linux
+   append = "cm206=0x340,11"
+   read-only
+
+
+If module parameters and LILO config options don't work
+-------------------------------------------------------
+If autoprobing does not work, you can hard-wire the default values
+of the base port address (CM206_BASE) and interrupt request line
+(CM206_IRQ) into the file ./include/linux/cm206.h. Change
+the defines of CM206_IRQ and CM206_BASE.
+
+
+Mounting the cdrom
+------------------
+1) Make sure that there is the right device installed in /dev.
+
+  	mknod /dev/cm206cd b 32 0
+
+2) Make sure there is a mount point, e.g., /cdrom 
+
+	mkdir /cdrom
+
+3) mount using a command like this (run as root):
+
+	mount -rt iso9660 /dev/cm206cd /cdrom
+
+4) For user-mounts, add a line in /etc/fstab
+
+	/dev/cm206cd      /cdrom     iso9660 	ro,noauto,user
+
+   This will allow users to give the commands
+
+	mount /cdrom
+	umount /cdrom
+
+If things don't work
+--------------------
+
+- Try to do a `dmesg' to find out if the driver said anything about
+  what is going wrong during the initialization.
+
+- Try to do a `dd if=/dev/cm206cd | od -tc | less' to read from the
+  CD.
+
+- Look in the /proc directory to see if `cm206' shows up under one of
+  `interrupts', `ioports', `devices' or `modules' (if applicable).
+
+
+DISCLAIMER 
+---------- 
+I cannot guarantee that this driver works, or that the hardware will
+not be harmed, although i consider it most unlikely. 
+
+I hope that you'll find this driver in some way useful. 
+
+					David van Leeuwen
+					david@tm.tno.nl
+
+Note for Linux CDROM vendors
+-----------------------------
+You are encouraged to include this driver on your Linux CDROM. If
+you do, you might consider sending me a free copy of that cd-rom.
+You can contact me through my e-mail address, david@tm.tno.nl. 
+If this driver is compiled into a kernel to boot off a cdrom, 
+you should actually send me a free copy of that cd-rom. 
+
+Copyright
+---------
+The copyright of the cm206 driver for Linux is 
+
+    (c) 1995 David A. van Leeuwen
+
+The driver is released under the conditions of the GNU general public
+license, which can be found in the file COPYING in the root of this
+source tree.
diff --git a/Documentation/cdrom/gscd b/Documentation/cdrom/gscd
new file mode 100644
index 000000000..66d4baabd
--- /dev/null
+++ b/Documentation/cdrom/gscd
@@ -0,0 +1,60 @@
+	Goldstar R420 CD-Rom device driver README
+
+For all kind of other information about the GoldStar R420 CDROM
+and this Linux device driver is a WWW-URL Page installed:
+
+        http://linux.rz.fh-hannover.de/~raupach        
+
+
+      If you are the editor of a Linux CD, you should
+      enable gscd.c within your boot floppy kernel. Please,
+      send me one of your CDs for free.
+
+
+This current driver version 0.4a only supports reading data from the disk.
+Currently we have no audio and no multisession or XA support.
+The polling interface is used, no DMA.
+
+
+Sometimes the GoldStar R420 is sold in a 'Reveal Multimedia Kit'. This kit's
+drive interface is compatible, too.
+
+
+Installation
+------------
+
+Change to '/usr/src/linux/include/linux' and edit the file 'gscd.h'. Insert
+the i/o address of your interface card.
+
+The default base address is 0x340. This will work for most applications. 
+Address selection is accomplished by jumpers PN801-1 to PN801-4 on the 
+GoldStar Interface Card.
+Appropriate settings are: 0x300, 0x310, 0x320, 0x330, 0x340, 0x350, 0x360
+0x370, 0x380, 0x390, 0x3A0, 0x3B0, 0x3C0, 0x3D0, 0x3E0, 0x3F0             
+
+Then go back to '/usr/src/linux/' and 'make config' to build the new
+configuration for your kernel. If you want to use the GoldStar driver
+like a module, don't select 'GoldStar CDROM support'. By the way, you
+have to include the iso9660 filesystem.
+
+Now start compiling the kernel with 'make dep ; make zImage'.
+If you want to use the driver as a module, you have to do 'make modules' 
+and 'make modules_install', additionally.
+Install your new kernel as usual - maybe you do it with 'make zlilo'.
+
+Before you can use the driver, you have to
+   mknod /dev/gscd0 b 16 0
+to create the appropriate device file (once for all times).
+
+If you use modules, you can try to insert the driver.
+Say: 'insmod /usr/src/linux/modules/gscd.o'
+or:  'insmod /usr/src/linux/modules/gscd.o gscd=<address>'
+The driver should report his results now.
+
+That's it! Mount a disk, i.e. 'mount -rt iso9660 /dev/gscd0 /cdrom'
+
+Feel free to report errors and suggestions to the following address.
+Be sure, I'm very happy to receive your comments!
+ 
+        Oliver Raupach                                Hannover, Juni 1995
+(raupach@nwfs1.rz.fh-hannover.de)
diff --git a/Documentation/cdrom/ide-cd b/Documentation/cdrom/ide-cd
new file mode 100644
index 000000000..f30fdfbf5
--- /dev/null
+++ b/Documentation/cdrom/ide-cd
@@ -0,0 +1,512 @@
+IDE-CD driver documentation
+19 May 1996
+scott snyder  <snyder@fnald0.fnal.gov>
+
+1. Introduction
+---------------
+
+The ide-cd driver should work with all ATAPI 1.2 compliant cdrom
+drives which attach to an IDE interface.  Note that some cdrom vendors
+(including Mitsumi, Sony, Creative, Aztech, and Goldstar) have made
+both ATAPI-compliant drives and drives which use a proprietary
+interface.  If your drive uses one of those proprietary interfaces,
+this driver will not work with it (but one of the other cdrom drivers
+probably will).  This driver will not work with `ATAPI' drives which
+attach to the parallel port.  In addition, there is at least one drive
+(CyCDROM CR520ie) which attaches to the IDE port but is not ATAPI;
+this driver will not work with drives like that either (but see the
+aztcd driver).
+
+This driver provides the following features:
+
+ - Reading from data tracks, and mounting iso9660 filesystems.
+
+ - Playing audio tracks.  Most of the cdrom player programs floating
+   around should work; i usually use Workman.
+
+ - Multisession support.
+
+ - On drives which support it, reading digital audio data directly
+   from audio tracks.  The program cdda2wav can be used for this.
+   Note, however, that only a few drives actually support this
+   function; the only ones which i've heard of successes with are Sony
+   and Toshiba drives.
+
+ - There is now support for cdrom changers which comply with the 
+   ATAPI 2.6 draft standard (such as the NEC CDR-251).  This additional
+   functionality includes a function call to query which slot is the
+   currently selected slot, a function call to query which slots contain
+   CDs, etc. A sample program which demonstrates this functionality is
+   appended to the end of this file.  The Sanyo 3-disc changer
+   (which does not conform to the standard) is also now supported.
+   Please note the driver refers to the first CD as slot # 0.
+
+
+2. Installation
+---------------
+
+0. The ide-cd relies on the ide disk driver.  See
+   Documentation/ide.txt for up-to-date information on the ide
+   driver.
+
+1. Make sure that the ide and ide-cd drivers are compiled into the
+   kernel you're using.  When configuring the kernel, say `yes' to the
+   options 
+
+      Enhanced IDE/MFM/RLL disk/cdrom/tape support
+      Include IDE/ATAPI CDROM support
+
+   and `no' to
+
+      Use old disk-only driver on primary interface
+
+   Depending on what type of IDE interface you have, you may need to
+   specify additional configuration options.  See
+   Documentation/ide.txt.
+
+2. You should also ensure that the iso9660 filesystem is either
+   compiled into the kernel or available as a loadable module.  You
+   can see if a filesystem is known to the kernel by cat'ing the file
+   /proc/filesystems.
+
+3. The cdrom drive should be connected to the host on an IDE
+   interface.  Each interface on a system is defined by an I/O port
+   address and an IRQ number, the standard assignments being
+   0x170 and 14 for the primary interface and 0x1f0 and 15 for the
+   secondary interface.  Each interface can control up to two devices,
+   where each device can be either a hard drive, a cdrom drive, or a
+   tape drive.  The two devices on an interface are called `master'
+   and `slave'; this is usually selectable via a jumper on the drive.
+
+   Linux names these devices as follows.  The master and slave devices
+   on the primary IDE interface are called `hda' and `hdb',
+   respectively.  The drives on the secondary interface are called
+   `hdc' and `hdd'.  (Interfaces at other locations get other letters
+   in the third position; see Documentation/ide.txt.)
+
+   If you want your cdrom drive to be found automatically by the
+   driver, you should make sure your IDE interface uses either the
+   primary or secondary addresses mentioned above.  In addition, if
+   the cdrom drive is the only device on the IDE interface, it should
+   be jumpered as `master'.  (If for some reason you cannot configure
+   your system in this manner, you can probably still use the driver.
+   You may have to pass extra configuration information to the kernel
+   when you boot, however.  See Documentation/ide.txt for more
+   information.)
+
+4. Boot the system.  If the drive is recognized, you should see a
+   message which looks like
+
+     hdb: NEC CD-ROM DRIVE:260, ATAPI CDROM drive
+
+   If you do not see this, see section 5 below.
+
+5. You may want to create a symbolic link /dev/cdrom pointing to the
+   actual device.  You can do this with the command
+
+     ln -s  /dev/hdX  /dev/cdrom
+
+   where X should be replaced by the letter indicating where your
+   drive is installed.
+
+6. You should be able to see any error messages from the driver with
+   the `dmesg' command.
+
+
+3. Basic usage
+--------------
+
+An iso9660 format cdrom can be mounted by putting the disc in the
+drive and typing (as root)
+
+  mount -t iso9660 /dev/cdrom /mnt/cdrom
+
+where it is assumed that /dev/cdrom is a link pointing to the actual
+device (as described in step 5 of the last section) and /mnt/cdrom is
+an empty directory.  You should now be able to see the contents of the
+cdrom under the /mnt/cdrom directory.  If you want to eject the cdrom,
+you must first dismount it with a command like
+
+  umount /mnt/cdrom
+
+Note that audio cds cannot be mounted.
+
+Some distributions set up /etc/fstab to always try to mount a cdrom
+filesystem on bootup.  It is not required to mount the cdrom in this
+manner, though, and it may be a nuisance if you change cdroms often.
+You should feel free to remove the cdrom line from /etc/fstab and
+mount cdroms manually if that suits you better.
+
+Multisession and photocd discs should work with no special handling.
+The hpcdtoppm package (ftp.gwdg.de:/pub/linux/hpcdtoppm/) may be
+useful for reading photocds.
+
+To play an audio cd, you should first unmount and remove any data
+cdrom.  Any of the cdrom player programs should then work (workman,
+workbone, cdplayer, etc.).  Lacking anything else, you could use the
+cdtester program in Documentation/cdrom/sbpcd.
+
+On a few drives, you can read digital audio directly using a program
+such as cdda2wav.  The only types of drive which i've heard support
+this are Sony and Toshiba drives.  You will get errors if you try to
+use this function on a drive which does not support it.
+
+For supported changers, you can use the `cdchange' program (appended to
+the end of this file) to switch between changer slots.  Note that the
+drive should be unmounted before attempting this.  The program takes
+two arguments: the cdrom device, and the slot number to which you wish
+to change.  If the slot number is -1, the drive is unloaded.
+
+
+4. Compilation options
+----------------------
+
+There are a few additional options which can be set when compiling the
+driver.  Most people should not need to mess with any of these; they
+are listed here simply for completeness.  A compilation option can be
+enabled by adding a line of the form `#define <option> 1' to the top
+of ide-cd.c.  All these options are disabled by default.
+
+VERBOSE_IDE_CD_ERRORS
+  If this is set, ATAPI error codes will be translated into textual
+  descriptions.  In addition, a dump is made of the command which
+  provoked the error.  This is off by default to save the memory used
+  by the (somewhat long) table of error descriptions.  
+
+STANDARD_ATAPI
+  If this is set, the code needed to deal with certain drives which do
+  not properly implement the ATAPI spec will be disabled.  If you know
+  your drive implements ATAPI properly, you can turn this on to get a
+  slightly smaller kernel.
+
+NO_DOOR_LOCKING
+  If this is set, the driver will never attempt to lock the door of
+  the drive.
+
+CDROM_NBLOCKS_BUFFER
+  This sets the size of the buffer to be used for a CDROMREADAUDIO
+  ioctl.  The default is 8.
+
+TEST
+  This presently enables an additional ioctl which enables a user-mode
+  program to execute an arbitrary packet command.  See the source for
+  details.  This should be left off unless you know what you're doing.
+
+
+5. Common problems
+------------------
+
+This section discusses some common problems encountered when trying to
+use the driver, and some possible solutions.  Note that if you are
+experiencing problems, you should probably also review
+Documentation/ide.txt for current information about the underlying
+IDE support code.  Some of these items apply only to earlier versions
+of the driver, but are mentioned here for completeness.
+
+In most cases, you should probably check with `dmesg' for any errors
+from the driver.
+
+a. Drive is not detected during booting.
+
+   - Review the configuration instructions above and in
+     Documentation/ide.txt, and check how your hardware is
+     configured.
+
+   - If your drive is the only device on an IDE interface, it should
+     be jumpered as master, if at all possible.
+
+   - If your IDE interface is not at the standard addresses of 0x170
+     or 0x1f0, you'll need to explicitly inform the driver using a
+     lilo option.  See Documentation/ide.txt.  (This feature was
+     added around kernel version 1.3.30.)
+
+   - If the autoprobing is not finding your drive, you can tell the
+     driver to assume that one exists by using a lilo option of the
+     form `hdX=cdrom', where X is the drive letter corresponding to
+     where your drive is installed (see section 2).  Note that if you
+     do this and you see a boot message like
+
+       hdX: ATAPI cdrom (?)
+
+     this does _not_ mean that the driver has successfully detected
+     the drive; rather, it means that the driver has not detected a
+     drive, but is assuming there's one there anyway because you told
+     it so.  If you actually try to do I/O to a drive defined at a
+     nonexistent or nonresponding I/O address, you'll probably get
+     errors with a status value of 0xff.
+
+   - Some IDE adapters require a nonstandard initialization sequence
+     before they'll function properly.  (If this is the case, there
+     will often be a separate MS-DOS driver just for the controller.)
+     IDE interfaces on sound cards often fall into this category.
+
+     Support for some interfaces needing extra initialization is
+     provided in later 1.3.x kernels.  You may need to turn on
+     additional kernel configuration options to get them to work;
+     see Documentation/ide.txt.
+
+     Even if support is not available for your interface, you may be
+     able to get it to work with the following procedure.  First boot
+     MS-DOS and load the appropriate drivers.  Then warm-boot linux
+     (i.e., without powering off).  If this works, it can be automated
+     by running loadlin from the MS-DOS autoexec.
+
+
+b. Timeout/IRQ errors.
+
+  - If you always get timeout errors, interrupts from the drive are
+    probably not making it to the host.
+
+  - IRQ problems may also be indicated by the message
+    `IRQ probe failed (<n>)' while booting.  If <n> is zero, that
+    means that the system did not see an interrupt from the drive when
+    it was expecting one (on any feasible IRQ).  If <n> is negative,
+    that means the system saw interrupts on multiple IRQ lines, when
+    it was expecting to receive just one from the cdrom drive.
+
+  - Double-check your hardware configuration to make sure that the IRQ
+    number of your IDE interface matches what the driver expects.
+    (The usual assignments are 14 for the primary (0x170) interface
+    and 15 for the secondary (0x1f0) interface.)  Also be sure that
+    you don't have some other hardware which might be conflicting with
+    the IRQ you're using.  Also check the BIOS setup for your system;
+    some have the ability to disable individual IRQ levels, and i've
+    had one report of a system which was shipped with IRQ 15 disabled
+    by default.
+
+  - Note that many MS-DOS cdrom drivers will still function even if
+    there are hardware problems with the interrupt setup; they
+    apparently don't use interrupts.
+
+
+c. System hangups.
+
+  - If the system locks up when you try to access the cdrom, the most
+    likely cause is that you have a buggy IDE adapter which doesn't
+    properly handle simultaneous transactions on multiple interfaces.
+    The most notorious of these is the CMD640B chip.  This problem can
+    be worked around by specifying the `serialize' option when
+    booting.  Recent kernels should be able to detect the need for
+    this automatically in most cases, but the detection is not
+    foolproof.  See Documentation/ide.txt for more information
+    about the `serialize' option and the CMD640B.
+
+  - Note that many MS-DOS cdrom drivers will work with such buggy
+    hardware, apparently because they never attempt to overlap cdrom
+    operations with other disk activity.
+
+
+d. Can't mount a cdrom.
+
+  - If you get errors from mount, it may help to check `dmesg' to see
+    if there are any more specific errors from the driver or from the
+    filesystem.
+
+  - Make sure there's a cdrom loaded in the drive, and that's it's an
+    iso9660 format disc.  You can't mount an audio cd.
+
+  - With the cdrom in the drive and unmounted, try something like
+
+      cat /dev/cdrom | od | more
+
+    If you see a dump, then the drive and driver are probably working
+    ok, and the problem is at the filesystem level (i.e., the cdrom is
+    not iso9660 format or has errors in the filesystem structure).
+
+  - If you see `not a block device' errors, check that the definitions
+    of the device special files are correct.  They should be as
+    follows:
+
+      brw-rw----   1 root     disk       3,   0 Nov 11 18:48 /dev/hda
+      brw-rw----   1 root     disk       3,  64 Nov 11 18:48 /dev/hdb
+      brw-rw----   1 root     disk      22,   0 Nov 11 18:48 /dev/hdc
+      brw-rw----   1 root     disk      22,  64 Nov 11 18:48 /dev/hdd
+
+    Some early Slackware releases had these defined incorrectly.  If
+    these are wrong, you can remake them by running the script
+    scripts/MAKEDEV.ide.  (You may have to make it executable
+    with chmod first.)
+
+    If you have a /dev/cdrom symbolic link, check that it is pointing
+    to the correct device file.
+
+    If you hear people talking of the devices `hd1a' and `hd1b', these
+    were old names for what are now called hdc and hdd.  Those names
+    should be considered obsolete.
+
+  - If mount is complaining that the iso9660 filesystem is not
+    available, but you know it is (check /proc/filesystems), you
+    probably need a newer version of mount.  Early versions would not
+    always give meaningful error messages.
+
+
+e. Directory listings are unpredictably truncated, and `dmesg' shows
+   `buffer botch' error messages from the driver.
+
+  - There was a bug in the version of the driver in 1.2.x kernels
+    which could cause this.  It was fixed in 1.3.0.  If you can't
+    upgrade, you can probably work around the problem by specifying a
+    blocksize of 2048 when mounting.  (Note that you won't be able to
+    directly execute binaries off the cdrom in that case.)
+
+    If you see this in kernels later than 1.3.0, please report it as a
+    bug.
+
+
+f. Data corruption.
+
+  - Random data corruption was occasionally observed with the Hitachi
+    CDR-7730 cdrom. If you experience data corruption, using "hdx=slow"
+    as a command line parameter may work around the problem, at the
+    expense of low system performance.
+
+
+6. cdchange.c
+-------------
+
+/*
+ * cdchange.c  [-v]  <device>  [<slot>]
+ *
+ * This load a cdrom from a specified slot in a changer, and displays 
+ * information about the changer status.  The drive should be unmounted before 
+ * using this program.
+ *
+ * Changer information is displayed if either the -v flag is specified
+ * or no slot was specified.
+ *
+ * Based on code originally from Gerhard Zuber <zuber@berlin.snafu.de>.
+ * Changer status information, and rewrite for the new common cdrom driver
+ * interface by Erik Andersen <andersee@et.byu.edu>.
+ */
+
+#include <stdlib.h>
+#include <errno.h>
+#include <string.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <linux/ucdrom.h>
+
+
+int
+main (int argc, char **argv)
+{
+	char *program;
+	char *device;
+	int fd;           /* file descriptor for CD-ROM device */
+	int status;       /* return status for system calls */
+	int verbose = 0;
+	int x_slot = -1;
+	int total_slots_available;
+
+	program = argv[0];
+
+	++argv;
+	--argc;
+
+	if (argc < 1 || argc > 3) {
+		fprintf (stderr, "usage: %s [-v] <device> [<slot>]\n",
+			 program);
+		fprintf (stderr, "       Slots are numbered 1 -- n.\n");
+		exit (1);
+	}
+ 
+       if (strcmp (argv[0], "-v") == 0) {
+                verbose = 1;
+                ++argv;
+                --argc;
+        }
+ 
+	device = argv[0];
+ 
+	if (argc == 2)
+		x_slot = atoi (argv[1]) - 1;
+
+	/* open device */ 
+	fd = open (device, 0);
+	if (fd < 0) {
+		fprintf (stderr, "%s: open failed for `%s': %s\n",
+			 program, device, strerror (errno));
+		exit (1);
+	}
+
+	/* Check CD player status */ 
+	total_slots_available = ioctl (fd, CDROM_CHANGER_NSLOTS);
+	if (total_slots_available <= 1 ) {
+		fprintf (stderr, "%s: Device `%s' is not an ATAPI "
+			"compliant CD changer.\n", program, device);
+		exit (1);
+	}
+
+	if (x_slot >= 0) {
+		if (x_slot >= total_slots_available) {
+			fprintf (stderr, "Bad slot number.  "
+				 "Should be 1 -- %d.\n",
+				 total_slots_available);
+			exit (1);
+		}
+
+		/* load */ 
+		status = ioctl (fd, CDROM_SELECT_DISC, x_slot);
+	}
+
+	if (x_slot < 0 || verbose) {
+
+		status = ioctl (fd, CDROM_SELECT_DISC, CDSL_CURRENT);
+
+		printf ("Current slot: %d\n", status+1);
+		printf ("Total slots available: %d\n",
+			total_slots_available);
+
+		printf ("Drive status: ");
+		switch (ioctl (fd, CDROM_DRIVE_STATUS, CDSL_CURRENT)) {
+		case CDS_DISC_OK:
+			printf ("Ready.\n");
+			break;
+		case CDS_TRAY_OPEN:
+			printf ("Tray Open.\n");
+			break;
+		case CDS_DRIVE_NOT_READY:
+			printf ("Drive Not Ready.\n");
+			break;
+		default:
+			printf ("This Should not happen!\n");
+			break;
+		}
+
+		for (x_slot=0; x_slot<total_slots_available; x_slot++) {
+			printf ("Slot %2d: ", x_slot+1);
+			switch (ioctl (fd, CDROM_DRIVE_STATUS, x_slot)) {
+			case CDS_DISC_OK:
+				printf ("Disc present.");
+				break;
+			case CDS_NO_DISC: 
+				printf ("Empty slot.");
+				break;
+			case CDS_NO_INFO:
+				printf ("No Information.");
+				break;
+			default:
+				printf ("This Should not happen!\n");
+				break;
+			}
+			switch (ioctl (fd, CDROM_MEDIA_CHANGED, x_slot)) {
+			case 1:
+				printf ("\t\tChanged.\n");
+				break;
+			default:
+				printf ("\n");
+				break;
+			}
+		}
+	}
+
+	/* close device */
+	status = close (fd);
+	if (status != 0) {
+		fprintf (stderr, "%s: close failed for `%s': %s\n",
+			 program, device, strerror (errno));
+		exit (1);
+	}
+ 
+	exit (0);
+}
diff --git a/Documentation/cdrom/isp16 b/Documentation/cdrom/isp16
new file mode 100644
index 000000000..2f43a42ec
--- /dev/null
+++ b/Documentation/cdrom/isp16
@@ -0,0 +1,100 @@
+ -- Documentation/cdrom/isp16
+
+Docs by Eric van der Maarel <H.T.M.v.d.Maarel@marin.nl>
+
+This is the README for version 0.6 of the cdrom interface on an
+ISP16, MAD16 or Mozart sound card.
+
+The detection and configuration of this interface used to be included
+in both the sjcd and optcd cdrom driver. Drives supported by these
+drivers came packed with Media Magic's multi media kit, which also
+included the ISP16 card. The idea (thanks Leo Spiekman)
+to move it from these drivers into a separate module and moreover, not to
+rely on the MAD16 sound driver, are as follows:
+-duplication of code in the kernel is a waste of resources and should
+ be avoided;
+-however, kernels and notably those included with Linux distributions
+ (cf Slackware 3.0 included version 0.5 of the isp16 configuration
+ code included in the drivers) don't always come with sound support
+ included. Especially when they already include a bunch of cdrom drivers.
+ Hence, the cdrom interface should be configurable _independently_ of
+ sound support.
+
+The ISP16, MAD16 and Mozart sound cards have an OPTi 82C928 or an
+OPTi 82C929 chip.  The interface on these cards should work with
+any cdrom attached to the card, which is 'electrically' compatible
+with Sanyo/Panasonic, Sony or Mitsumi non-ide drives. However, the
+command sets for any proprietary drives may differ
+(and hence may not be supported in the kernel) from these four types.
+For a fact I know the interface works and the way of configuration
+as described in this documentation works in combination with the
+sjcd (in Sanyo/Panasonic compatibility mode) cdrom drivers
+(probably with the optcd (in Sony compatibility mode) as well).
+If you have such an OPTi based sound card and you want to use the
+cdrom interface with a cdrom drive supported by any of the other cdrom
+drivers, it will probably work. Please let me know any experience you
+might have).
+I understand that cards based on the OPTi 82C929 chips may be configured
+(hardware jumpers that is) as an IDE interface. Initialisation of such a
+card in this mode is not supported (yet?).
+
+The suggestion to configure the ISP16 etc. sound card by booting DOS and 
+do a warm reboot to boot Linux somehow doesn't work, at least not
+on my machine (IPC P90), with the OPTi 82C928 based card.
+
+Booting the kernel through the boot manager LILO allows the use
+of some command line options on the 'LILO boot:' prompt. At boot time
+press Alt or Shift while the LILO prompt is written on the screen and enter
+any kernel options. Alternatively these options may be used in
+the appropriate section in /etc/lilo.conf. Adding 'append="<cmd_line_options>"'
+will do the trick as well.
+The syntax of 'cmd_line_options' is
+
+        isp16=[<port>[,<irq>[,<dma>]]][[,]<drive_type>]
+
+If there is no ISP16 or compatibles detected, there's probably no harm done.
+These options indicate the values that your cdrom drive has been (or will be)
+configured to use.
+Valid values for the base i/o address are:
+  port=0x340,0x320,0x330,0x360
+for the interrupt request number 
+  irq=0,3,5,7,9,10,11
+for the direct memory access line
+  dma=0,3,5,6,7
+and for the type of drive
+  drive_type=noisp16,Sanyo,Panasonic,Sony,Mitsumi.
+Note that these options are case sensitive.
+The values 0 for irq and dma indicate that they are not used, and
+the drive will be used in 'polling' mode. The values 5 and 7 for irq
+should be avoided in order to avoid any conflicts with optional
+sound card configuration.
+The syntax of the command line does not allow the specification of
+irq when there's nothing specified for the base address and no
+specification of dma when there is no specification of irq.
+The value 'nosip16' for drive_type, which may be used as the first
+non-integer option value (e.g. 'isp16=noisp16'), makes sure that probing
+for and subsequent configuration of an ISP16-compatible card is skipped
+all together. This can be useful to overcome possible conflicts which
+may arise while the kernel is probing your hardware.
+The default values are
+  port=0x340
+  irq=0
+  dma=0
+  drive_type=Sanyo
+reflecting my own configuration. The defaults can be changed in
+the file ~/include/linux/ips16.h.
+
+The cdrom interface can be configured at run time by loading the
+initialisation driver as a module. In that case, the interface
+parameters can be set by giving appropriate values on the command
+line. Configuring the driver can then be done by the following
+command (assuming you have iso16.o installed in a proper place):
+
+  insmod isp16.o isp16_cdrom_base=<port> isp16_cdrom_irq=<irq> \
+    isp16_cdrom_dma=<dma> isp16_cdrom_type=<drive_type>
+
+where port, irq, dma and drive_type can have any of the values mentioned
+above.
+
+
+Have fun!
diff --git a/Documentation/cdrom/mcd b/Documentation/cdrom/mcd
new file mode 100644
index 000000000..39537f9f0
--- /dev/null
+++ b/Documentation/cdrom/mcd
@@ -0,0 +1,4 @@
+This driver does not support XA or MultiSession CDs (PhotoCDs). Use the
+experimental driver mcdx.c for that.
+
+You can use mcd for one interface, and mcdx for another.
diff --git a/Documentation/cdrom/mcdx b/Documentation/cdrom/mcdx
new file mode 100644
index 000000000..fd2c37321
--- /dev/null
+++ b/Documentation/cdrom/mcdx
@@ -0,0 +1,44 @@
+This is a first attempt to create an `improved' driver for the Mitsumi drives.
+It is able to "live together" with mcd.c, if you have at least two Mitsumi
+drives: each driver can use his own drive.
+
+To allow this "coexistence" as long as mcdx.c is not a superset of mcd.c,
+this driver has to use its own device files. We use MAJOR 20 for it. So,
+you have to do
+
+ # mknod /dev/mcdx0 b 20 0
+ # mknod /dev/mcdx1 b 20 1
+
+and so on, one entry for each drive to support, once.
+
+If you are using the driver as a module, you can specify your ports and IRQs
+like
+
+ # insmod mcdx.o mcdx=0x300,11,0x304,5
+
+and so on ("address,IRQ" pairs).
+This will override the configuration in mcdx.h.
+
+This driver:
+
+    o   handles XA (and hopefully) multi session CDs as well as
+        ordinary CDs;
+    o   supports up to 5 drives (of course, you'll need free 
+        IRQs, i/o ports and slots);
+    o   uses much less kernel memory than the standard mcd driver
+        (no extra driver internal buffers!).
+        o   plays audio (like the `old' driver, I hope)
+
+This version doesn't support yet:
+
+    o   shared IRQs (but it seems to be possible - I've successfully
+                connected two drives to the same irq.  So it's `only' a 
+                problem of the driver.)
+
+This driver never will:
+
+    o   Read digital audio (i.e. copy directly), due to missing
+        hardware features. 
+
+
+heiko@lotte.sax.de
diff --git a/Documentation/cdrom/optcd b/Documentation/cdrom/optcd
new file mode 100644
index 000000000..6f46c7adb
--- /dev/null
+++ b/Documentation/cdrom/optcd
@@ -0,0 +1,57 @@
+This is the README file for the Optics Storage 8000 AT CDROM device driver.
+
+This is the driver for the so-called 'DOLPHIN' drive, with the 34-pin
+Sony-compatible interface. For the IDE-compatible Optics Storage 8001
+drive, you will want the ATAPI CDROM driver. The driver also seems to
+work with the Lasermate CR328A. If you have a drive that works with
+this driver, and that doesn't report itself as DOLPHIN, please drop me
+a mail.
+
+The support for multisession CDs is in ALPHA stage. If you use it,
+please mail me your experiences. Multisession support can be disabled
+at compile time.
+
+You can find some older versions of the driver at
+      dutette.et.tudelft.nl:/pub/linux/
+and at Eberhard's mirror
+      ftp.gwdg.de:/pub/linux/cdrom/drivers/optics/
+
+Before you can use the driver, you have to create the device file once:
+ # mknod /dev/optcd0 b 17 0
+
+To specify the base address if the driver is "compiled-in" to your kernel,
+you can use the kernel command line item (LILO option)
+             optcd=0x340
+with the right address.
+
+If you have compiled optcd as a module, you can load it with
+ # insmod /usr/src/linux/modules/optcd.o
+or
+ # insmod /usr/src/linux/modules/optcd.o optcd=0x340
+with the matching address value of your interface card.
+
+The driver employs a number of buffers to do read-ahead and block size
+conversion. The number of buffers is configurable in optcd.h, and has
+influence on the driver performance. For my machine (a P75), 6 buffers
+seems optimal, as can be seen from this table:
+
+#bufs	kb/s	%cpu
+1	97	0.1
+2	191	0.3
+3	188	0.2
+4	246	0.3
+5	189	19
+6	280	0.4
+7	281	7.0
+8	246	2.8
+16	281	3.4
+
+If you get a throughput significantly below 300 kb/s, try tweaking
+N_BUFS, and don't forget to mail me your results!
+
+I'd appreciate success/failure reports. If you find a bug, try
+recompiling the driver with some strategically chosen debug options
+(these can be found in optcd.h) and include the messages generated in
+your bug report. Good luck.
+
+Leo Spiekman (spiekman@dutette.et.tudelft.nl)
diff --git a/Documentation/cdrom/sbpcd b/Documentation/cdrom/sbpcd
new file mode 100644
index 000000000..dca6a2f93
--- /dev/null
+++ b/Documentation/cdrom/sbpcd
@@ -0,0 +1,1064 @@
+This README belongs to release 4.2 or newer of the SoundBlaster Pro
+(Matsushita, Kotobuki, Panasonic, CreativeLabs, Longshine and Teac)
+CD-ROM driver for Linux.
+
+sbpcd really, really is NOT for ANY IDE/ATAPI drive!
+Not even if you have an "original" SoundBlaster card with an IDE interface!
+So, you better have a look into README.ide if your port address is 0x1F0,
+0x170, 0x1E8, 0x168 or similar.
+I get tons of mails from IDE/ATAPI drive users - I really can't continue
+any more to answer them all. So, if your drive/interface information sheets
+mention "IDE" (primary, secondary, tertiary, quaternary) and the DOS driver
+invoking line within your CONFIG.SYS is using an address below 0x230:
+DON'T ROB MY LAST NERVE - jumper your interface to address 0x170 and IRQ 15
+(that is the "secondary IDE" configuration), set your drive to "master" and
+use ide-cd as your driver. If you do not have a second IDE hard disk, use the
+LILO commands
+   hdb=noprobe hdc=cdrom
+and get lucky.
+To make it fully clear to you: if you mail me about IDE/ATAPI drive problems,
+my answer is above, and I simply will discard your mail, hoping to stop the
+flood and to find time to lead my 12-years old son towards happy computing.
+
+The driver is able to drive the whole family of "traditional" AT-style (that
+is NOT the new "Enhanced IDE" or "ATAPI" drive standard) Matsushita,
+Kotobuki, Panasonic drives, sometimes labelled as "CreativeLabs". The
+well-known drives are CR-521, CR-522, CR-523, CR-562, CR-563.
+CR-574 is an IDE/ATAPI drive.
+
+The Longshine LCS-7260 is a double-speed drive which uses the "old"
+Matsushita command set. It is supported - with help by Serge Robyns.
+Vertos ("Elitegroup Computer Systems", ECS) has a similar drive - support
+has started; come in contact if you have such a "Vertos 100" or "ECS-AT"
+drive.
+
+There exists an "IBM External ISA CD-ROM Drive" which in fact is a CR-563
+with a special controller board. This drive is supported (the interface is
+of the "LaserMate" type), and it is possibly the best buy today (cheaper than
+an internal drive, and you can use it as an internal, too - f.e. plug it into
+a soundcard).
+
+CreativeLabs has a new drive "CD200" and a similar drive "CD200F". The latter
+is made by Funai and sometimes named "E2550UA", newer models may be named
+"MK4015". The CD200F drives should fully work.
+CD200 drives without "F" are still giving problems: drive detection and
+playing audio should work, data access will result in errors. I need qualified
+feedback about the bugs within the data functions or a drive (I never saw a
+CD200).
+
+The quad-speed Teac CD-55A drive is supported, but still does not reach "full
+speed". The data rate already reaches 500 kB/sec if you set SBP_BUFFER_FRAMES
+to 64 (it is not recommended to do that for normal "file access" usage, but it
+can speed up things a lot if you use something like "dd" to read from the
+drive; I use it for verifying self-written CDs this way).
+The drive itself is able to deliver 600 kB/sec, so this has to get a point of
+work; with the normal setup, the performance currently is not even as good as
+double-speed.
+
+This driver is NOT for Mitsumi or Sony or Aztech or Philips or XXX drives,
+and again: this driver is in no way usable for any IDE/ATAPI drive. If you 
+think your drive should work and it doesn't: send me the DOS driver for your
+beast (gzipped + uuencoded) and your CONFIG.SYS if you want to ask me for help,
+and include an original log message excerpt, and try to give all information
+a complete idiot needs to understand your hassle already with your first
+mail. And if you want to say "as I have mailed you before", be sure that I
+don't remember your "case" by such remarks; at the moment, I have some 
+hundreds open correspondences about Linux CDROM questions (hope to reduce if
+the IDE/ATAPI user questions disappear). 
+
+
+This driver will work with the soundcard interfaces (SB Pro, SB 16, Galaxy,
+SoundFX, Mozart, MAD16 ...) and with the "no-sound" cards (Panasonic CI-101P,
+LaserMate, WDH-7001C, Longshine LCS-6853, Teac ...).
+
+It works with the "configurable" interface "Sequoia S-1000", too, which is 
+used on the Spea Media FX and Ensonic Soundscape sound cards. You have to
+specify the type "SBPRO 2" and the true CDROM port address with it, not the
+"configuration port" address.
+
+If you have a sound card which needs a "configuration driver" instead of
+jumpers for interface types and addresses (like Mozart cards) - those
+drivers get invoked before the DOS CDROM driver in your CONFIG.SYS, typical
+names are "cdsetup.sys" and "mztinit.sys" -, let the sound driver do the
+CDROM port configuration (the leading comments in linux/drivers/sound/mad16.c
+are just for you!). Hannu Savolainen's mad16.c code is able to set up my
+Mozart card - I simply had to add
+   #define MAD16_CONF 0x06
+   #define MAD16_CDSEL 0x03
+to configure the CDROM interface for type "Panasonic" (LaserMate) and address
+0x340.
+
+The interface type has to get configured in /usr/include/linux/sbpcd.h, 
+because the register layout is different between the "SoundBlaster" and the
+"LaserMate" type.
+
+I got a report that the Teac interface card "I/F E117098" is of type
+"SoundBlaster" (i.e. you have to set SBPRO to 1) even with the addresses
+0x300 and above. This is unusual, and it can't get covered by the auto
+probing scheme.
+The Teac 16-bit interface cards (like P/N E950228-00A, default address 0x2C0)
+need the SBPRO 3 setup.
+
+If auto-probing found the drive, the address is correct. The reported type
+may be wrong. A "mount" will give success only if the interface type is set
+right. Playing audio should work with a wrong set interface type, too.
+
+With some Teac and some CD200 drives I have seen interface cards which seem
+to lack the "drive select" lines; always drive 0 gets addressed. To avoid
+"mirror drives" (four drives detected where you only have one) with such
+interface cards, set MAX_DRIVES to 1 and jumper your drive to ID 0 (if
+possible).
+
+
+Up to 4 drives per interface card, and up to 4 interface cards are supported.
+All supported drive families can be mixed, but the CR-521 drives are 
+hard-wired to drive ID 0. The drives have to use different drive IDs, and each
+drive has to get a unique minor number (0...3), corresponding indirectly to 
+its drive ID.
+The drive IDs may be selected freely from 0 to 3 - they do not have to be in
+consecutive order.
+
+As Don Carroll, don@ds9.us.dell.com or FIDO 1:382/14, told me, it is possible
+to change old drives to any ID, too. He writes in this sense:
+   "In order to be able to use more than one single speed drive
+   (they do not have the ID jumpers) you must add a DIP switch
+   and two resistors. The pads are already on the board next to
+   the power connector. You will see the silkscreen for the
+   switch if you remove the top cover.
+                    1 2 3 4
+             ID 0 = x F F x             O = "on"
+             ID 1 = x O F x             F = "off"
+             ID 2 = x F O x             x = "don't care"
+             ID 3 = x O O x
+   Next to the switch are the positions for R76 (7k) and R78
+   (12k). I had to play around with the resistor values - ID 3
+   did not work with other values. If the values are not good,
+   ID 3 behaves like ID 0."
+
+To use more than 4 drives, you simply need a second controller card at a 
+different address and a second cable.
+
+The driver supports reading of data from the CD and playing of audio tracks.
+The audio part should run with WorkMan, xcdplayer, with the "non-X11" products
+CDplayer and WorkBone - tell me if it is not compatible with other software.
+The only accepted measure for correctness with the audio functions is the
+"cdtester" utility (appended) - most audio player programmers seem to be
+better musicians than programmers. ;-)
+
+With the CR-56x and the CD200 drives, the reading of audio frames is possible.
+This is implemented by an IOCTL function which reads READ_AUDIO frames of
+2352 bytes at once (configurable with the "READ_AUDIO" define, default is 0).
+Reading the same frame a second time gives different data; the frame data 
+start at a different position, but all read bytes are valid, and we always
+read 98 consecutive chunks (of 24 Bytes) as a frame. Reading more than 1 frame
+at once possibly misses some chunks at each frame boundary. This lack has to
+get corrected by external, "higher level" software which reads the same frame 
+again and tries to find and eliminate overlapping chunks (24-byte-pieces).
+
+The transfer rate with reading audio (1-frame-pieces) currently is very slow.
+This can be better reading bigger chunks, but the "missing" chunks possibly
+occur at the beginning of each single frame.
+The software interface possibly may change a bit the day the SCSI driver
+supports it too.
+
+With all but the CR-52x drives, MultiSession is supported.
+Photo CDs work (the "old" drives like CR-521 can access only the first
+session of a photoCD).
+At ftp.gwdg.de:/pub/linux/hpcdtoppm/ you will find Hadmut Danisch's package to
+convert photo CD image files and Gerd Knorr's viewing utility.
+
+The transfer rate will reach 150 kB/sec with CR-52x drives, 300 kB/sec with
+CR-56x drives, and currently not more than 500 kB/sec (usually less than
+250 kB/sec) with the Teac quad speed drives.
+XA (PhotoCD) disks with "old" drives give only 50 kB/sec.
+
+This release consists of
+- this README file
+- the driver file linux/drivers/cdrom/sbpcd.c
+- the stub files linux/drivers/cdrom/sbpcd[234].c
+- the header file linux/include/linux/sbpcd.h.
+
+
+To install:
+-----------
+
+1. Setup your hardware parameters. Though the driver does "auto-probing" at a
+   lot of (not all possible!) addresses, this step is recommended for
+   every-day use. You should let sbpcd auto-probe once and use the reported
+   address if a drive got found. The reported type may be incorrect; it is
+   correct if you can mount a data CD. There is no choice for you with the
+   type; only one is the right, the others are deadly wrong.
+
+   a. Go into /usr/src/linux/include/linux/sbpcd.h and configure it for your
+      hardware (near the beginning):
+      a1. Set it up for the appropriate type of interface board.
+          "Original" CreativeLabs sound cards need "SBPRO 1".
+          Most "compatible" sound cards (almost all "non-CreativeLabs" cards)
+          need "SBPRO 0".
+          The "no-sound" board from OmniCd needs the "SBPRO 1" setup.
+          The Teac 8-bit "no-sound" boards need the "SBPRO 1" setup.
+          The Teac 16-bit "no-sound" boards need the "SBPRO 3" setup.
+          All other "no-sound" boards need the "SBPRO 0" setup.
+          The Spea Media FX and Ensoniq SoundScape cards need "SBPRO 2".
+          sbpcd.c holds some examples in its auto-probe list.
+          If you configure "SBPRO" wrong, the playing of audio CDs will work,
+          but you will not be able to mount a data CD.
+      a2. Tell the address of your CDROM_PORT (not of the sound port).
+      a3. If 4 drives get found, but you have only one, set MAX_DRIVES to 1.
+      a4. Set DISTRIBUTION to 0.
+   b. Additionally for 2.a1 and 2.a2, the setup may be done during
+      boot time (via the "kernel command line" or "LILO option"):
+          sbpcd=0x320,LaserMate
+      or
+          sbpcd=0x230,SoundBlaster
+      or
+          sbpcd=0x338,SoundScape
+      or
+          sbpcd=0x2C0,Teac16bit
+      This is especially useful if you install a fresh distribution.
+      If the second parameter is a number, it gets taken as the type
+      setting; 0 is "LaserMate", 1 is "SoundBlaster", 2 is "SoundScape",
+      3 is "Teac16bit".
+      So, for example
+          sbpcd=0x230,1
+      is equivalent to
+          sbpcd=0x230,SoundBlaster
+
+2. "cd /usr/src/linux" and do a "make config" and select "y" for Matsushita
+   CD-ROM support and for ISO9660 FileSystem support. If you do not have a
+   second, third, or fourth controller installed, do not say "y" to the 
+   secondary Matsushita CD-ROM questions.
+
+3. Then do a "make dep", then make the kernel image ("make zlilo" or else).
+
+4. Make the device file(s). This step usually already has been done by the
+   MAKEDEV script.
+   The driver uses MAJOR 25, so, if necessary, do
+        mknod /dev/sbpcd  b 25 0       (if you have only one drive)
+   and/or
+        mknod /dev/sbpcd0 b 25 0
+        mknod /dev/sbpcd1 b 25 1
+        mknod /dev/sbpcd2 b 25 2
+        mknod /dev/sbpcd3 b 25 3
+   to make the node(s).
+
+   The "first found" drive gets MINOR 0 (regardless to its jumpered ID), the
+   "next found" (at the same cable) gets MINOR 1, ...
+   
+   For a second interface board, you have to make nodes like
+        mknod /dev/sbpcd4 b 26 0
+        mknod /dev/sbpcd5 b 26 1
+   and so on. Use the MAJORs 26, 27, 28.
+
+   If you further make a link like
+        ln -s sbpcd /dev/cdrom
+   you can use the name /dev/cdrom, too.
+
+5. Reboot with the new kernel.
+
+You should now be able to do
+              mkdir /CD
+and 
+              mount -rt iso9660 /dev/sbpcd /CD
+or
+              mount -rt iso9660 -o block=2048 /dev/sbpcd /CD
+and see the contents of your CD in the /CD directory.
+To use audio CDs, a mounting is not recommended (and it would fail if the
+first track is not a data track).
+
+
+Using sbpcd as a "loadable module":
+-----------------------------------
+
+If you do NOT select "Matsushita/Panasonic CDROM driver support" during the
+"make config" of your kernel, you can build the "loadable module" sbpcd.o.
+Read /usr/src/linux/Documentation/modules.txt on this.
+
+If sbpcd gets used as a module, the support of more than one interface
+card (i.e. drives 4...15) is disabled.
+
+You can specify interface address and type with the "insmod" command like:
+ # insmod /usr/src/linux/modules/sbpcd.o sbpcd=0x340,0
+or
+ # insmod /usr/src/linux/modules/sbpcd.o sbpcd=0x230,1
+or
+ # insmod /usr/src/linux/modules/sbpcd.o sbpcd=0x338,2
+where the last number represents the SBPRO setting (no strings allowed here).
+
+
+Things of interest:
+-------------------
+
+The driver is configured to try the LaserMate type of interface at I/O port
+0x0340 first. If this is not appropriate, sbpcd.h should get changed
+(you will find the right place - just at the beginning).
+
+No DMA and no IRQ is used.
+
+To reduce or increase the amount of kernel messages, edit sbpcd.c and play
+with the "DBG_xxx" switches (initialization of the variable "sbpcd_debug").
+Don't forget to reflect what you do; enabling all DBG_xxx switches at once
+may crash your system, and each message line is accompanied by a delay.
+
+The driver uses the "variable BLOCK_SIZE" feature. To use it, you have to
+specify "block=2048" as a mount option. Doing this will disable the direct
+execution of a binary from the CD; you have to copy it to a device with the
+standard BLOCK_SIZE (1024) before. So, do not use this if your system is
+directly "running from the CDROM" (like some of YGGDRASIL's installation
+variants). There are CDs on the market (like the german "unifix" Linux
+distribution) which MUST get handled with a block_size of 1024. Generally,
+one can say all the CDs which hold files of the name YMTRANS.TBL are defective;
+do not use block=2048 with those.
+
+Within sbpcd.h, you will find some "#define"s (f.e. EJECT and JUKEBOX). With
+that, you can configure the driver for some special things.
+You can use the appended program "cdtester" to set the auto-eject feature
+during runtime. Jeff Tranter's "eject" utility can do this, too (and more)
+for you.
+
+There is an ioctl CDROMMULTISESSION to obtain with a user program if
+the CD is an XA disk and - if it is - where the last session starts. The
+"cdtester" program illustrates how to call it.
+
+
+Auto-probing at boot time:
+--------------------------
+
+The driver does auto-probing at many well-known interface card addresses,
+but not all:
+Some probings can cause a hang if an NE2000 ethernet card gets touched, because
+SBPCD's auto-probing happens before the initialization of the net drivers.
+Those "hazardous" addresses are excluded from auto-probing; the "kernel 
+command line" feature has to be used during installation if you have your 
+drive at those addresses. The "module" version is allowed to probe at those
+addresses, too.
+
+The auto-probing looks first at the configured address resp. the address
+submitted by the kernel command line. With this, it is possible to use this
+driver within installation boot floppies, and for any non-standard address,
+too.
+
+Auto-probing will make an assumption about the interface type ("SBPRO" or not),
+based upon the address. That assumption may be wrong (initialization will be
+o.k., but you will get I/O errors during mount). In that case, use the "kernel
+command line" feature and specify address & type at boot time to find out the
+right setup.
+
+For every-day use, address and type should get configured within sbpcd.h. That
+will stop the auto-probing due to success with the first try.
+
+The kernel command "sbpcd=0" suppresses each auto-probing and causes
+the driver not to find any drive; it is meant for people who love sbpcd
+so much that they do not want to miss it, even if they miss the drives. ;-)  
+
+If you configure "#define CDROM_PORT 0" in sbpcd.h, the auto-probing is
+initially disabled and needs an explicit kernel command to get activated.
+Once activated, it does not stop before success or end-of-list. This may be
+useful within "universal" CDROM installation boot floppies (but using the 
+loadable module would be better because it allows an "extended" auto-probing
+without fearing NE2000 cards).
+
+To shorten the auto-probing list to a single entry, set DISTRIBUTION 0 within
+sbpcd.h.
+
+
+Setting up address and interface type:
+--------------------------------------
+
+If your I/O port address is not 0x340, you have to look for the #defines near
+the beginning of sbpcd.h and configure them: set SBPRO to 0 or 1 or 2, and
+change CDROM_PORT to the address of your CDROM I/O port.
+
+Almost all of the "SoundBlaster compatible" cards behave like the no-sound
+interfaces, i.e. need SBPRO 0! 
+
+With "original" SB Pro cards, an initial setting of CD_volume through the
+sound cards MIXER register gets done.
+If you are using a "compatible" sound card of types "LaserMate" or "SPEA",
+you can set SOUND_BASE (in sbpcd.h) to get it done with your card, too...
+
+
+Using audio CDs:
+----------------
+
+Workman, WorkBone, xcdplayer, cdplayer and the nice little tool "cdplay" (see
+README.aztcd from the Aztech driver package) should work.
+
+The program CDplayer likes to talk to "/dev/mcd" only, xcdplayer wants
+"/dev/rsr0", workman loves "/dev/sr0" or "/dev/cdrom" - so, do the appropriate
+links for using them without the need of supplying parameters.
+
+
+Copying audio tracks:
+---------------------
+
+The following program will copy track 1 (or a piece of it) from an audio CD
+into the file "track01":
+
+/*=================== begin program ========================================*/
+/*
+ * read an audio track from a CD
+ *
+ * (c) 1994 Eberhard Moenkeberg <emoenke@gwdg.de>
+ *          may be used & enhanced freely
+ *
+ * Due to non-existent sync bytes at the beginning of each audio frame (or due
+ * to a firmware bug within all known drives?), it is currently a kind of
+ * fortune if two consecutive frames fit together.
+ * Usually, they overlap, or a little piece is missing. This happens in units
+ * of 24-byte chunks. It has to get fixed by higher-level software (reading
+ * until an overlap occurs, and then eliminate the overlapping chunks). 
+ * ftp.gwdg.de:/pub/linux/misc/cdda2wav-sbpcd.*.tar.gz holds an example of
+ * such an algorithm.
+ * This example program further is missing to obtain the SubChannel data
+ * which belong to each frame.
+ *
+ * This is only an example of the low-level access routine. The read data are
+ * pure 16-bit CDDA values; they have to get converted to make sound out of
+ * them.
+ * It is no fun to listen to it without prior overlap/underlap correction!
+ */
+#include <stdio.h>
+#include <sys/ioctl.h>
+#include <linux/cdrom.h>
+
+static struct cdrom_tochdr hdr;
+static struct cdrom_tocentry entry[101];
+static struct cdrom_read_audio arg;
+static u_char buffer[CD_FRAMESIZE_RAW];
+static int datafile, drive;
+static int i, j, limit, track, err;
+static char filename[32];
+
+main(int argc, char *argv[])
+{
+/*
+ * open /dev/cdrom
+ */
+  drive=open("/dev/cdrom", 0);
+  if (drive<0)
+    {
+      fprintf(stderr, "can't open drive.\n");
+      exit (-1);
+    }
+/*
+ * get TocHeader
+ */
+  fprintf(stdout, "getting TocHeader...\n");
+  err=ioctl(drive, CDROMREADTOCHDR, &hdr);
+  if (err!=0)
+    {
+      fprintf(stderr, "can't get TocHeader (error %d).\n", err);
+      exit (-1);
+    }
+  else
+    fprintf(stdout, "TocHeader: %d %d\n", hdr.cdth_trk0, hdr.cdth_trk1);
+/*
+ * get and display all TocEntries
+ */
+  fprintf(stdout, "getting TocEntries...\n");
+  for (i=1;i<=hdr.cdth_trk1+1;i++)
+    {
+      if (i!=hdr.cdth_trk1+1) entry[i].cdte_track = i;
+      else entry[i].cdte_track = CDROM_LEADOUT;
+      entry[i].cdte_format = CDROM_LBA;
+      err=ioctl(drive, CDROMREADTOCENTRY, &entry[i]);
+      if (err!=0)
+	{
+	  fprintf(stderr, "can't get TocEntry #%d (error %d).\n", i, err);
+	  exit (-1);
+	}
+      else
+	{
+	  fprintf(stdout, "TocEntry #%d: %1X %1X %06X %02X\n",
+		 entry[i].cdte_track,
+		 entry[i].cdte_adr,
+		 entry[i].cdte_ctrl,
+		 entry[i].cdte_addr.lba,
+		 entry[i].cdte_datamode);
+	}
+    }
+  fprintf(stdout, "got all TocEntries.\n");
+/*
+ * ask for track number (not implemented here)
+ */
+track=1;
+#if 0 /* just read a little piece (4 seconds) */
+entry[track+1].cdte_addr.lba=entry[track].cdte_addr.lba+300;
+#endif
+/*
+ * read track into file
+ */
+  sprintf(filename, "track%02d\0", track);
+  datafile=creat(filename, 0755);
+  if (datafile<0)
+    {
+      fprintf(stderr, "can't open datafile %s.\n", filename);
+      exit (-1);
+    }
+  arg.addr.lba=entry[track].cdte_addr.lba;
+  arg.addr_format=CDROM_LBA; /* CDROM_MSF would be possible here, too. */
+  arg.nframes=1;
+  arg.buf=&buffer[0];
+  limit=entry[track+1].cdte_addr.lba;
+  for (;arg.addr.lba<limit;arg.addr.lba++)
+    {
+      err=ioctl(drive, CDROMREADAUDIO, &arg);
+      if (err!=0)
+	{
+	  fprintf(stderr, "can't read abs. frame #%d (error %d).\n", 
+		 arg.addr.lba, err);
+	}
+      j=write(datafile, &buffer[0], CD_FRAMESIZE_RAW);
+      if (j!=CD_FRAMESIZE_RAW)
+	{
+	  fprintf(stderr,"I/O error (datafile) at rel. frame %d\n",
+			 arg.addr.lba-entry[track].cdte_addr.lba);
+	}
+      arg.addr.lba++;
+    }
+}
+/*===================== end program ========================================*/
+
+At ftp.gwdg.de:/pub/linux/misc/cdda2wav-sbpcd.*.tar.gz is an adapted version of
+Heiko Eissfeldt's digital-audio to .WAV converter (the original is there, too).
+This is preliminary, as Heiko himself will care about it.
+
+
+Known problems:
+---------------
+
+Currently, the detection of disk change or removal is actively disabled.
+
+Most attempts to read the UPC/EAN code result in a stream of zeroes. All my
+drives are mostly telling there is no UPC/EAN code on disk or there is, but it
+is an all-zero number. I guess now almost no CD holds such a number.
+
+Bug reports, comments, wishes, donations (technical information is a donation,
+too :-) etc. to emoenke@gwdg.de.
+
+SnailMail address, preferable for CD editors if they want to submit a free
+"cooperation" copy:
+                         Eberhard Moenkeberg
+                         Reinholdstr. 14
+                         D-37083 Goettingen
+                         Germany
+---
+
+
+Appendix -- the "cdtester" utility:
+
+/*
+ * cdtester.c -- test the audio functions of a CD driver
+ *
+ * (c) 1995 Eberhard Moenkeberg <emoenke@gwdg.de>
+ *          published under the GPL
+ *
+ *          made under heavy use of the "Tiny Audio CD Player"
+ *          from Werner Zimmermann <zimmerma@rz.fht-esslingen.de>
+ *          (see linux/drivers/block/README.aztcd)
+ */
+#undef AZT_PRIVATE_IOCTLS /* not supported by every CDROM driver */
+#define SBP_PRIVATE_IOCTLS /* not supported by every CDROM driver */
+
+#include <stdio.h>
+#include <stdio.h>
+#include <malloc.h>
+#include <sys/ioctl.h>
+#include <linux/cdrom.h>
+
+#ifdef AZT_PRIVATE_IOCTLS
+#include <linux/aztcd.h>
+#endif AZT_PRIVATE_IOCTLS
+#ifdef SBP_PRIVATE_IOCTLS
+#include <linux/sbpcd.h>
+#include <linux/fs.h>
+#endif SBP_PRIVATE_IOCTLS
+
+struct cdrom_tochdr hdr;
+struct cdrom_tochdr tocHdr;
+struct cdrom_tocentry TocEntry[101];
+struct cdrom_tocentry entry;
+struct cdrom_multisession ms_info;
+struct cdrom_read_audio read_audio;
+struct cdrom_ti ti;
+struct cdrom_subchnl subchnl;
+struct cdrom_msf msf;
+struct cdrom_volctrl volctrl;
+#ifdef AZT_PRIVATE_IOCTLS
+union
+{
+	struct cdrom_msf msf;
+	unsigned char buf[CD_FRAMESIZE_RAW];
+} azt;
+#endif AZT_PRIVATE_IOCTLS
+int i, i1, i2, i3, j, k;
+unsigned char sequence=0;
+unsigned char command[80];
+unsigned char first=1, last=1;
+char *default_device="/dev/cdrom";
+char dev[20];
+char filename[20];
+int drive;
+int datafile;
+int rc;
+
+void help(void)
+{
+	printf("Available Commands:\n");
+	printf("STOP          s      EJECT        e       QUIT         q\n");
+	printf("PLAY TRACK    t      PAUSE        p       RESUME       r\n");
+	printf("NEXT TRACK    n      REPEAT LAST  l       HELP         h\n");
+	printf("SUBCHANNEL_Q  c      TRACK INFO   i       PLAY AT      a\n");
+	printf("READ          d      READ RAW     w       READ AUDIO   A\n");
+	printf("MS-INFO       M      TOC          T       START        S\n");
+	printf("SET EJECTSW   X      DEVICE       D       DEBUG        Y\n");
+	printf("AUDIO_BUFSIZ  Z      RESET        R       BLKRASET     B\n");
+	printf("SET VOLUME    v      GET VOLUME   V\n");
+}
+
+/*
+ *  convert MSF number (3 bytes only) to Logical_Block_Address 
+ */
+int msf2lba(u_char *msf)
+{
+	int i;
+	
+	i=(msf[0] * CD_SECS + msf[1]) * CD_FRAMES + msf[2] - CD_BLOCK_OFFSET;
+	if (i<0) return (0);
+	return (i);
+}
+/*
+ *  convert logical_block_address to m-s-f_number (3 bytes only)
+ */
+void lba2msf(int lba, unsigned char *msf)
+{
+	lba += CD_BLOCK_OFFSET;
+	msf[0] = lba / (CD_SECS*CD_FRAMES);
+	lba %= CD_SECS*CD_FRAMES;
+	msf[1] = lba / CD_FRAMES;
+	msf[2] = lba % CD_FRAMES;
+}
+
+int init_drive(char *dev)
+{
+	unsigned char msf_ent[3];
+
+	/*
+	 * open the device
+	 */
+	drive=open(dev,0);
+	if (drive<0) return (-1);
+	/*
+	 * get TocHeader
+	 */
+	printf("getting TocHeader...\n");
+	rc=ioctl(drive,CDROMREADTOCHDR,&hdr);
+	if (rc!=0)
+	{
+		printf("can't get TocHeader (error %d).\n",rc);
+		return (-2);
+	}
+	else
+		first=hdr.cdth_trk0;
+		last=hdr.cdth_trk1;
+		printf("TocHeader: %d %d\n",hdr.cdth_trk0,hdr.cdth_trk1);
+	/*
+	 * get and display all TocEntries
+	 */
+	printf("getting TocEntries...\n");
+	for (i=1;i<=hdr.cdth_trk1+1;i++)
+	{
+		if (i!=hdr.cdth_trk1+1) TocEntry[i].cdte_track = i;
+		else TocEntry[i].cdte_track = CDROM_LEADOUT;
+		TocEntry[i].cdte_format = CDROM_LBA;
+		rc=ioctl(drive,CDROMREADTOCENTRY,&TocEntry[i]);
+		if (rc!=0)
+		{
+			printf("can't get TocEntry #%d (error %d).\n",i,rc);
+		}
+		else
+		{
+			lba2msf(TocEntry[i].cdte_addr.lba,&msf_ent[0]);
+			if (TocEntry[i].cdte_track==CDROM_LEADOUT)
+			{
+				printf("TocEntry #%02X: %1X %1X %02d:%02d:%02d (lba: 0x%06X) %02X\n",
+				       TocEntry[i].cdte_track,
+				       TocEntry[i].cdte_adr,
+				       TocEntry[i].cdte_ctrl,
+				       msf_ent[0],
+				       msf_ent[1],
+				       msf_ent[2],
+				       TocEntry[i].cdte_addr.lba,
+				       TocEntry[i].cdte_datamode);
+			}
+			else
+			{
+				printf("TocEntry #%02d: %1X %1X %02d:%02d:%02d (lba: 0x%06X) %02X\n",
+				       TocEntry[i].cdte_track,
+				       TocEntry[i].cdte_adr,
+				       TocEntry[i].cdte_ctrl,
+				       msf_ent[0],
+				       msf_ent[1],
+				       msf_ent[2],
+				       TocEntry[i].cdte_addr.lba,
+				       TocEntry[i].cdte_datamode);
+			}
+		}
+	}
+	return (hdr.cdth_trk1); /* number of tracks */
+}
+
+void display(int size,unsigned char *buffer)
+{
+	k=0;
+	getchar();
+	for (i=0;i<(size+1)/16;i++)
+	{
+		printf("%4d:",i*16);
+		for (j=0;j<16;j++)
+		{
+			printf(" %02X",buffer[i*16+j]);
+		}
+		printf("  ");
+		for (j=0;j<16;j++)
+		{
+			if (isalnum(buffer[i*16+j])) 
+				printf("%c",buffer[i*16+j]);
+			else
+				printf(".");
+		}
+		printf("\n"); 
+		k++;
+		if (k>=20)
+		{
+			printf("press ENTER to continue\n");
+			getchar();
+			k=0;
+		}
+	} 
+} 
+
+main(int argc, char *argv[])
+{
+	printf("\nTesting tool for a CDROM driver's audio functions V0.1\n");
+	printf("(C) 1995 Eberhard Moenkeberg <emoenke@gwdg.de>\n");
+	printf("initializing...\n");
+	
+	rc=init_drive(default_device);
+	if (rc<0) printf("could not open %s (rc=%d).\n",default_device,rc);
+	help();
+	while (1)
+	{
+		printf("Give a one-letter command (h = help): ");
+		scanf("%s",command);
+		command[1]=0;
+		switch (command[0])
+		{
+		case 'D':
+			printf("device name (f.e. /dev/sbpcd3): ? ");
+			scanf("%s",&dev);
+			close(drive);
+			rc=init_drive(dev);
+			if (rc<0) printf("could not open %s (rc %d).\n",dev,rc);
+			break;
+		case 'e':
+			rc=ioctl(drive,CDROMEJECT);
+			if (rc<0) printf("CDROMEJECT: rc=%d.\n",rc);
+			break;
+		case 'p':
+			rc=ioctl(drive,CDROMPAUSE);
+			if (rc<0) printf("CDROMPAUSE: rc=%d.\n",rc);
+			break;
+		case 'r':
+			rc=ioctl(drive,CDROMRESUME);
+			if (rc<0) printf("CDROMRESUME: rc=%d.\n",rc);
+			break;
+		case 's':
+			rc=ioctl(drive,CDROMSTOP);
+			if (rc<0) printf("CDROMSTOP: rc=%d.\n",rc);
+			break;
+		case 'S':
+			rc=ioctl(drive,CDROMSTART);
+			if (rc<0) printf("CDROMSTART: rc=%d.\n",rc);
+			break;
+		case 't':
+			rc=ioctl(drive,CDROMREADTOCHDR,&tocHdr);
+			if (rc<0)
+			{
+				printf("CDROMREADTOCHDR: rc=%d.\n",rc);
+				break;
+			}
+			first=tocHdr.cdth_trk0;
+			last= tocHdr.cdth_trk1;
+			if ((first==0)||(first>last))
+			{
+				printf ("--got invalid TOC data.\n");
+			}
+			else
+			{
+				printf("--enter track number(first=%d, last=%d): ",first,last);
+				scanf("%d",&i1);
+				ti.cdti_trk0=i1;
+				if (ti.cdti_trk0<first) ti.cdti_trk0=first;
+				if (ti.cdti_trk0>last) ti.cdti_trk0=last;
+				ti.cdti_ind0=0;
+				ti.cdti_trk1=last;
+				ti.cdti_ind1=0;
+				rc=ioctl(drive,CDROMSTOP);
+				rc=ioctl(drive,CDROMPLAYTRKIND,&ti);
+				if (rc<0) printf("CDROMPLAYTRKIND: rc=%d.\n",rc);
+			}
+			break;
+		case 'n':
+			rc=ioctl(drive,CDROMSTOP);
+			if (++ti.cdti_trk0>last) ti.cdti_trk0=last;
+			ti.cdti_ind0=0;
+			ti.cdti_trk1=last;
+			ti.cdti_ind1=0;
+			rc=ioctl(drive,CDROMPLAYTRKIND,&ti);
+			if (rc<0) printf("CDROMPLAYTRKIND: rc=%d.\n",rc);
+			break;
+		case 'l':
+			rc=ioctl(drive,CDROMSTOP);
+			if (--ti.cdti_trk0<first) ti.cdti_trk0=first;
+			ti.cdti_ind0=0;
+			ti.cdti_trk1=last;
+			ti.cdti_ind1=0;
+			rc=ioctl(drive,CDROMPLAYTRKIND,&ti);
+			if (rc<0) printf("CDROMPLAYTRKIND: rc=%d.\n",rc);
+			break;
+		case 'c':
+			subchnl.cdsc_format=CDROM_MSF;
+			rc=ioctl(drive,CDROMSUBCHNL,&subchnl);
+			if (rc<0) printf("CDROMSUBCHNL: rc=%d.\n",rc);
+			else
+			{
+				printf("AudioStatus:%s  Track:%d  Mode:%d  MSF=%02d:%02d:%02d\n",
+				       subchnl.cdsc_audiostatus==CDROM_AUDIO_PLAY ? "PLAYING":"NOT PLAYING",
+				       subchnl.cdsc_trk,subchnl.cdsc_adr, 
+				       subchnl.cdsc_absaddr.msf.minute,
+				       subchnl.cdsc_absaddr.msf.second,
+				       subchnl.cdsc_absaddr.msf.frame);
+			}
+			break;              
+		case 'i':
+			printf("Track No.: ");
+			scanf("%d",&i1);
+			entry.cdte_track=i1;
+			if (entry.cdte_track<first) entry.cdte_track=first;
+			if (entry.cdte_track>last)  entry.cdte_track=last;
+			entry.cdte_format=CDROM_MSF;
+			rc=ioctl(drive,CDROMREADTOCENTRY,&entry);
+			if (rc<0) printf("CDROMREADTOCENTRY: rc=%d.\n",rc);
+			else
+			{
+				printf("Mode %d Track, starts at %02d:%02d:%02d\n",
+				       entry.cdte_adr,
+				       entry.cdte_addr.msf.minute,
+				       entry.cdte_addr.msf.second,
+				       entry.cdte_addr.msf.frame);
+			}
+			break;
+		case 'a':
+			printf("Address (min:sec:frm)  ");
+			scanf("%d:%d:%d",&i1,&i2,&i3);
+			msf.cdmsf_min0=i1;
+			msf.cdmsf_sec0=i2;
+			msf.cdmsf_frame0=i3;
+			if (msf.cdmsf_sec0>59) msf.cdmsf_sec0=59;
+			if (msf.cdmsf_frame0>74) msf.cdmsf_frame0=74;
+			lba2msf(TocEntry[last+1].cdte_addr.lba-1,&msf.cdmsf_min1);
+			rc=ioctl(drive,CDROMSTOP);
+			rc=ioctl(drive,CDROMPLAYMSF,&msf);
+			if (rc<0) printf("CDROMPLAYMSF: rc=%d.\n",rc);
+			break;
+		case 'V':
+			rc=ioctl(drive,CDROMVOLREAD,&volctrl);
+			if (rc<0) printf("CDROMVOLCTRL: rc=%d.\n",rc);
+			printf("Volume: channel 0 (left) %d, channel 1 (right) %d\n",volctrl.channel0,volctrl.channel1);
+			break;  
+		case 'R':
+			rc=ioctl(drive,CDROMRESET);
+			if (rc<0) printf("CDROMRESET: rc=%d.\n",rc);
+			break;
+		case 'B': /* set the driver's (?) read ahead value */
+			printf("enter read-ahead size: ? ");
+			scanf("%d",&i);
+			rc=ioctl(drive,BLKRASET,i);
+			if (rc<0) printf("BLKRASET: rc=%d.\n",rc);
+			break;
+#ifdef AZT_PRIVATE_IOCTLS /*not supported by every CDROM driver*/
+		case 'd':
+			printf("Address (min:sec:frm)  ");
+			scanf("%d:%d:%d",&i1,&i2,&i3);
+			azt.msf.cdmsf_min0=i1;
+			azt.msf.cdmsf_sec0=i2;
+			azt.msf.cdmsf_frame0=i3;
+			if (azt.msf.cdmsf_sec0>59) azt.msf.cdmsf_sec0=59;
+			if (azt.msf.cdmsf_frame0>74) azt.msf.cdmsf_frame0=74;
+			rc=ioctl(drive,CDROMREADMODE1,&azt.msf);
+			if (rc<0) printf("CDROMREADMODE1: rc=%d.\n",rc);
+			else display(CD_FRAMESIZE,azt.buf);
+			break;
+		case 'w':
+			printf("Address (min:sec:frame)  ");
+			scanf("%d:%d:%d",&i1,&i2,&i3);
+			azt.msf.cdmsf_min0=i1;
+			azt.msf.cdmsf_sec0=i2;
+			azt.msf.cdmsf_frame0=i3;
+			if (azt.msf.cdmsf_sec0>59) azt.msf.cdmsf_sec0=59;
+			if (azt.msf.cdmsf_frame0>74) azt.msf.cdmsf_frame0=74;
+			rc=ioctl(drive,CDROMREADMODE2,&azt.msf);
+			if (rc<0) printf("CDROMREADMODE2: rc=%d.\n",rc);
+			else display(CD_FRAMESIZE_RAW,azt.buf); /* currently only 2336 */
+			break;  
+#endif
+		case 'v':
+			printf("--Channel 0 (Left)  (0-255): ");
+			scanf("%d",&i1);
+			volctrl.channel0=i1;
+			printf("--Channel 1 (Right) (0-255): ");
+			scanf("%d",&i1);
+			volctrl.channel1=i1;
+			volctrl.channel2=0;
+			volctrl.channel3=0;
+			rc=ioctl(drive,CDROMVOLCTRL,&volctrl);
+			if (rc<0) printf("CDROMVOLCTRL: rc=%d.\n",rc);
+			break;  
+		case 'q':
+			close(drive);
+			exit(0);
+		case 'h':
+			help();
+			break;
+		case 'T': /* display TOC entry - without involving the driver */
+			scanf("%d",&i);
+			if ((i<hdr.cdth_trk0)||(i>hdr.cdth_trk1))
+				printf("invalid track number.\n");
+			else
+				printf("TocEntry %02d: adr=%01X ctrl=%01X msf=%02d:%02d:%02d mode=%02X\n",
+				       TocEntry[i].cdte_track,
+				       TocEntry[i].cdte_adr,
+				       TocEntry[i].cdte_ctrl,
+				       TocEntry[i].cdte_addr.msf.minute,
+				       TocEntry[i].cdte_addr.msf.second,
+				       TocEntry[i].cdte_addr.msf.frame,
+				       TocEntry[i].cdte_datamode);
+			break;
+		case 'A': /* read audio data into file */
+			printf("Address (min:sec:frm) ? ");
+			scanf("%d:%d:%d",&i1,&i2,&i3);
+			read_audio.addr.msf.minute=i1;
+			read_audio.addr.msf.second=i2;
+			read_audio.addr.msf.frame=i3;
+			read_audio.addr_format=CDROM_MSF;
+			printf("# of frames ? ");
+			scanf("%d",&i1);
+			read_audio.nframes=i1;
+			k=read_audio.nframes*CD_FRAMESIZE_RAW;
+			read_audio.buf=malloc(k);
+			if (read_audio.buf==NULL)
+			{
+				printf("can't malloc %d bytes.\n",k);
+				break;
+			}
+			sprintf(filename,"audio_%02d%02d%02d_%02d.%02d\0",
+				read_audio.addr.msf.minute,
+				read_audio.addr.msf.second,
+				read_audio.addr.msf.frame,
+				read_audio.nframes,
+				++sequence);
+			datafile=creat(filename, 0755);
+			if (datafile<0)
+			{
+				printf("can't open datafile %s.\n",filename);
+				break;
+			}
+			rc=ioctl(drive,CDROMREADAUDIO,&read_audio);
+			if (rc!=0)
+			{
+				printf("CDROMREADAUDIO: rc=%d.\n",rc);
+			}
+			else
+			{
+				rc=write(datafile,&read_audio.buf,k);
+				if (rc!=k) printf("datafile I/O error (%d).\n",rc);
+			}
+			close(datafile);
+			break;
+		case 'X': /* set EJECT_SW (0: disable, 1: enable auto-ejecting) */
+			scanf("%d",&i);
+			rc=ioctl(drive,CDROMEJECT_SW,i);
+			if (rc!=0)
+				printf("CDROMEJECT_SW: rc=%d.\n",rc);
+			else
+				printf("EJECT_SW set to %d\n",i);
+			break;
+		case 'M': /* get the multisession redirection info */
+			ms_info.addr_format=CDROM_LBA;
+			rc=ioctl(drive,CDROMMULTISESSION,&ms_info);
+			if (rc!=0)
+			{
+				printf("CDROMMULTISESSION(lba): rc=%d.\n",rc);
+			}
+			else
+			{
+				if (ms_info.xa_flag) printf("MultiSession offset (lba): %d (0x%06X)\n",ms_info.addr.lba,ms_info.addr.lba);
+				else
+				{
+					printf("this CD is not an XA disk.\n");
+					break;
+				}
+			}
+			ms_info.addr_format=CDROM_MSF;
+			rc=ioctl(drive,CDROMMULTISESSION,&ms_info);
+			if (rc!=0)
+			{
+				printf("CDROMMULTISESSION(msf): rc=%d.\n",rc);
+			}
+			else
+			{
+				if (ms_info.xa_flag)
+					printf("MultiSession offset (msf): %02d:%02d:%02d (0x%02X%02X%02X)\n",
+					       ms_info.addr.msf.minute,
+					       ms_info.addr.msf.second,
+					       ms_info.addr.msf.frame,
+					       ms_info.addr.msf.minute,
+					       ms_info.addr.msf.second,
+					       ms_info.addr.msf.frame);
+				else printf("this CD is not an XA disk.\n");
+			}
+			break;
+#ifdef SBP_PRIVATE_IOCTLS
+		case 'Y': /* set the driver's message level */
+#if 0 /* not implemented yet */
+			printf("enter switch name (f.e. DBG_CMD): ");
+			scanf("%s",&dbg_switch);
+			j=get_dbg_num(dbg_switch);
+#else
+			printf("enter DDIOCSDBG switch number: ");
+			scanf("%d",&j);
+#endif
+			printf("enter 0 for \"off\", 1 for \"on\": ");
+			scanf("%d",&i);
+			if (i==0) j|=0x80;
+			printf("calling \"ioctl(drive,DDIOCSDBG,%d)\"\n",j);
+			rc=ioctl(drive,DDIOCSDBG,j);
+			printf("DDIOCSDBG: rc=%d.\n",rc);
+			break;
+		case 'Z': /* set the audio buffer size */
+			printf("# frames wanted: ? ");
+			scanf("%d",&j);
+			rc=ioctl(drive,CDROMAUDIOBUFSIZ,j);
+			printf("%d frames granted.\n",rc);
+			break;
+#endif SBP_PRIVATE_IOCTLS
+		default:
+			printf("unknown command: \"%s\".\n",command);
+			break;
+		}
+	}
+}
+/*==========================================================================*/
+
diff --git a/Documentation/cdrom/sjcd b/Documentation/cdrom/sjcd
new file mode 100644
index 000000000..5357b9c9b
--- /dev/null
+++ b/Documentation/cdrom/sjcd
@@ -0,0 +1,60 @@
+ -- Documentation/cdrom/sjcd
+				80% of the work takes 20% of the time,
+				20% of the work takes 80% of the time...
+						(Murphy law)
+
+				Once started, training can not be stopped...
+						(StarWars)
+
+This is the README for the sjcd cdrom driver, version 1.6.
+
+This file is meant as a tips & tricks edge for the usage of the SANYO CDR-H94A
+cdrom drive. It will grow as the questions arise. ;-)
+For info on configuring the ISP16 sound card look at Documentation/cdrom/isp16.
+
+The driver should work with any of the Panasonic, Sony or Mitsumi style
+CDROM interface.
+The cdrom interface on Media Magic's soft configurable sound card ISP16,
+which used to be included in the driver, is now supported in a separate module.
+This initialisation module will probably also work with other interfaces
+based on an OPTi 82C928 or 82C929 chip (like MAD16 and Mozart): see the
+documentation Documentation/cdrom/isp16.
+
+The device major for sjcd is 18, and minor is 0. Create a block special
+file in your /dev directory (e.g., /dev/sjcd) with these numbers.
+(For those who don't know, being root and doing the following should do
+the trick:
+  mknod -m 644 /dev/sjcd b 18 0
+and mount the cdrom by /dev/sjcd).
+
+The default configuration parameters are:
+  base address 0x340
+  no irq
+  no dma
+(Actually the CDR-H94A doesn't know how to use irq and dma.)
+As of version 1.2, setting base address at boot time is supported
+through the use of command line options: type at the "boot:" prompt:
+  linux sjcd=<base_address>
+(where you would use the kernel labeled "linux" in lilo's configuration
+file /etc/lilo.conf). You could also use 'append="sjcd=<configuration_info>"'
+in the appropriate section of /etc/lilo.conf
+If you're building a kernel yourself you can set your default base
+i/o address with SJCD_BASE_ADDR in include/linux/sjcd.h.
+
+The sjcd driver supports being loaded as a module. The following
+command will set the base i/o address on the fly (assuming you
+have installed the module in an appropriate place).
+  insmod sjcd.o sjcd_base=<base_address>
+
+
+Have fun!
+
+If something is wrong, please email to		vadim@rbrf.ru
+					or 	vadim@ipsun.ras.ru
+					or	model@cecmow.enet.dec.com
+					or	H.T.M.v.d.Maarel@marin.nl
+
+It happens sometimes that Vadim is not reachable by mail. For these
+instances, Eric van der Maarel will help too.
+
+		Vadim V. Model, Eric van der Maarel, Eberhard Moenkeberg
diff --git a/Documentation/cdrom/sonycd535 b/Documentation/cdrom/sonycd535
new file mode 100644
index 000000000..71d3a8649
--- /dev/null
+++ b/Documentation/cdrom/sonycd535
@@ -0,0 +1,121 @@
+              README FOR LINUX SONY CDU-535/531 DRIVER
+              ========================================
+
+This is the the Sony CDU-535 (and 531) driver version 0.7 for Linux.
+I do not think I have the documentation to add features like DMA support
+so if anyone else wants to pursue it or help me with it, please do.
+(I need to see what was done for the CDU-31A driver -- perhaps I can
+steal some of that code.)
+
+This is a Linux device driver for the Sony CDU-535 CDROM drive.  This is
+one of the older Sony drives with its own interface card (Sony bus).
+The DOS driver for this drive is named SONY_CDU.SYS - when you boot DOS
+your drive should be identified as a SONY CDU-535.  The driver works
+with a CDU-531 also.  One user reported that the driver worked on drives
+OEM'ed by Procomm, drive and interface board were labelled Procomm.
+
+The Linux driver is based on Corey Minyard's sonycd 0.3 driver for
+the CDU-31A.  Ron Jeppesen just changed the commands that were sent
+to the drive to correspond to the CDU-535 commands and registers.
+There were enough changes to let bugs creep in but it seems to be stable.
+Ron was able to tar an entire CDROM (should read all blocks) and built
+ghostview and xfig off Walnut Creek's X11R5/GNU CDROM.  xcdplayer and
+workman work with the driver.  Others have used the driver without
+problems except those dealing with wait loops (fixed in third release).
+Like Minyard's original driver this one uses a polled interface (this
+is also the default setup for the DOS driver).  It has not been tried
+with interrupts or DMA enabled on the board.
+
+REQUIREMENTS
+============
+
+	- Sony CDU-535 drive, preferably without interrupts and DMA 
+	  enabled on the card.
+
+	- Drive must be set up as unit 1.  Only the first unit will be 
+	  recognized
+
+	- you must enter your interface address into 
+          /usr/src/linux/include/linux/sonycd535.h and build the
+          appropriate kernel or use the "kernel command line" parameter
+                sonycd535=0x320
+          with the correct interface address.
+
+NOTES:
+======
+
+1) The drive MUST be turned on when booting or it will not be recognized!
+   (but see comments on modularized version below)
+
+2) when the cdrom device is opened the eject button is disabled to keep the
+   user from ejecting a mounted disk and replacing it with another.
+   Unfortunately xcdplayer and workman also open the cdrom device so you
+   have to use the eject button in the software.  Keep this in mind if your
+   cdrom player refuses to give up its disk -- exit workman or xcdplayer, or
+   umount the drive if it has been mounted.
+
+THANKS
+======
+
+Many thanks to Ron Jeppesen (ronj.an@site007.saic.com) for getting
+this project off the ground.  He wrote the initial release
+and the first two patches to this driver (0.1, 0.2, and 0.3).
+Thanks also to Eberhard Moenkeberg (emoenke@gwdg.de) for prodding
+me to place this code into the mainstream Linux source tree
+(as of Linux version 1.1.91), as well as some patches to make
+it a better device citizen.  Further thanks to "S. Joel Katz"
+<stimpson@panix.com> for his MODULE patches (see details below),
+Porfiri Claudio <C.Porfiri@nisms.tei.ericsson.se> for patches
+to make the driver work with the older CDU-510/515 series, and
+Heiko Eissfeldt <heiko@colossus.escape.de> for pointing out that
+the verify_area() checks were ignoring the results of said checks.
+
+(Acknowledgments from Ron Jeppesen in the 0.3 release:)
+Thanks to Corey Minyard who wrote the original CDU-31A driver on which
+this driver is based.  Thanks to Ken Pizzini and Bob Blair who provided 
+patches and feedback on the first release of this driver.
+
+Ken Pizzini
+ken@halcyon.com
+
+------------------------------------------------------------------------------
+(The following is from Joel Katz <Stimpson@Panix.COM>.)
+
+	To build a version of sony535.o that can be installed as a module,
+use the following command:
+
+gcc -c -D__KERNEL__ -DMODULE -O2 sonycd535.c -o sonycd535.o
+
+	To install the module, simply type:
+
+insmod sony535.o
+	or
+insmod sony535.o sonycd535=<address>
+
+	And to remove it:
+
+rmmod sony535
+
+	The code checks to see if MODULE is defined and behaves as it used
+to if MODULE is not defined. That means your patched file should behave
+exactly as it used to if compiled into the kernel.
+
+	I have an external drive, and I usually leave it powered off. I used
+to have to reboot if I needed to use the CDROM drive. Now I don't.
+
+	Even if you have an internal drive, why waste the 268K of memory
+(unswappable) that the driver uses if you use your CD-ROM drive infrequently?
+
+	This driver will not install (whether compiled in or loaded as a
+module) if the CDROM drive is not available during its initialization. This
+means that you can have the driver compiled into the kernel and still load
+the module later (assuming the driver doesn't install itself during
+power-on). This only wastes 12K when you boot with the CDROM drive off.
+
+	This is what I usually do; I leave the driver compiled into the
+kernel, but load it as a module if I powered the system up with the drive
+off and then later decided to use the CDROM drive.
+
+	Since the driver only uses a single page to point to the chunks,
+attempting to set the buffer cache to more than 2 Megabytes would be very
+bad; don't do that.
diff --git a/Documentation/devices.tex b/Documentation/devices.tex
new file mode 100644
index 000000000..f7997b9a9
--- /dev/null
+++ b/Documentation/devices.tex
@@ -0,0 +1,1270 @@
+\documentstyle{article}
+%
+% Adopt somewhat reasonable margins, so it doesn't take a million
+% pages to print... :-)  If you're actually putting this in print, you
+% may wish to change these.
+%
+\oddsidemargin=0in
+\textwidth=6.5in
+\topmargin=0in
+\headheight=0.5in
+\headsep=0.25in
+\textheight=7.5in
+\footskip=0.75in
+\footheight=0.5in
+%
+\begin{document}
+\newcommand{\file}{\tt}			% Style to use for a filename
+\newcommand{\hex}{\tt}			% Style to use for a hex number
+\newcommand{\ud}{(Under development)}	% Abbreviation
+\newcommand{\1}{\({}^1\)}
+\newcommand{\2}{\({}^2\)}
+\newcommand{\3}{\({}^3\)}
+\newcommand{\4}{\({}^4\)}
+\newlength{\dig}
+\settowidth{\dig}{0}			% Get width of digits
+\newcommand{\num}[2]{\makebox[#1\dig][r]{#2}}
+\newcommand{\major}[4]{\num{3}{#1}#2 \> #3 \> #4 \\}
+\newcommand{\minor}[3]{\> \> \num{3}{#1} \> {\file #2} \> #3 \\}
+\newcommand{\minordots}{\> \> \> \dots \\}
+\newenvironment{devicelist}%
+ {\begin{tabbing}%
+000--000 \= blockxxx \= 000 \= {\file /dev/crambamboli} \= foo \kill}%
+ {\end{tabbing}}
+\newcommand{\link}[4]{{\file #1} \> {\file #2} \> #3 \> #4 \\}
+\newcommand{\vlink}[4]{{\file #1} \> {\em #2 \/} \> #3 \> #4 \\}
+\newcommand{\node}[3]{{\file #1} \> #2 \> #3 \\}
+\newenvironment{nodelist}%
+ {\begin{tabbing}%
+{\file /dev/crambamboli} \= {\file /proc/self/fd/99} \= symbolicxxx \=
+foo \kill}%
+ {\end{tabbing}}
+%
+\title{{\bf Linux Allocated Devices}}
+\author{Maintained by H. Peter Anvin $<$hpa@zytor.com$>$}
+\date{Last revised: November 18, 1996}
+\maketitle
+%
+\noindent
+This list is the successor to Rick Miller's Linux Device List, which
+he stopped maintaining when he got busy with other things in 1993.  It
+is a registry of allocated major device numbers, as well as the
+recommended {\file /dev} directory nodes for these devices.
+
+The latest version of this list is included with the Linux kernel
+sources in \LaTeX\ and ASCII form.  In case of discrepancy, the
+\LaTeX\ version is authoritative.
+
+This document is included by reference into the Linux Filesystem
+Standard (FSSTND).  The FSSTND is available via FTP from
+tsx-11.mit.edu in the directory {\file
+/pub/linux/docs/linux-standards/fsstnd}.
+
+To have a major number allocated, or a minor number in situations
+where that applies (e.g.\ busmice), please contact me with the
+appropriate device information.  Also, if you have additional
+information regarding any of the devices listed below, or if I have
+made a mistake, I would greatly appreciate a note.  When sending me
+mail, please include the word ``device'' in the subject so your mail
+won't accidentally get buried!
+
+Allocations marked (68k/Amiga) apply to Linux/68k on the Amiga
+platform only.  Allocations marked (68k/Atari) apply to Linux/68k on
+the Atari platform only.
+
+This document is in the public domain.  The author requests, however,
+that semantically altered versions are not distributed without
+permission of the author, assuming the author can be contacted without
+an unreasonable effort.
+
+In particular, please don't sent patches for this list to Linus, at
+least not without contacting me first.
+
+I do not have any information about these devices beyond what appears
+on this list.  Any such information requests will be deleted without
+reply.
+
+\section{Major numbers}
+
+\begin{devicelist}
+\major{ 0}{}{     }{Unnamed devices (e.g. non-device mounts)}
+\major{ 1}{}{char }{Memory devices}
+\major{  }{}{block}{RAM disk}
+\major{ 2}{}{char }{Pseudo-TTY masters}
+\major{  }{}{block}{Floppy disks}
+\major{ 3}{}{char }{Pseudo-TTY slaves}
+\major{  }{}{block}{First MFM, RLL and IDE hard disk/CD-ROM interface}
+\major{ 4}{}{char }{TTY devices}
+\major{ 5}{}{char }{Alternate TTY devices}
+\major{ 6}{}{char }{Parallel printer devices}
+\major{ 7}{}{char }{Virtual console access devices}
+\major{  }{}{block}{Loopback devices}
+\major{ 8}{}{block}{SCSI disk devices}
+\major{ 9}{}{char }{SCSI tape devices}
+\major{  }{}{block}{Metadisk (RAID) devices}
+\major{10}{}{char }{Non-serial mice, misc features}
+\major{11}{}{char }{Raw keyboard device}
+\major{  }{}{block}{SCSI CD-ROM devices}
+\major{12}{}{char }{QIC-02 tape}
+\major{  }{}{block}{MSCDEX CD-ROM callback support}
+\major{13}{}{char }{PC speaker}
+\major{  }{}{block}{8-bit MFM/RLL/IDE controller}
+\major{14}{}{char }{Sound card}
+\major{  }{}{block}{BIOS harddrive callback support}
+\major{15}{}{char }{Joystick}
+\major{  }{}{block}{Sony CDU-31A/CDU-33A CD-ROM}
+\major{16}{}{char }{Non-SCSI scanners}
+\major{  }{}{block}{GoldStar CD-ROM}
+\major{17}{}{char }{Chase serial card}
+\major{  }{}{block}{Optics Storage CD-ROM}
+\major{18}{}{char }{Chase serial card -- alternate devices}
+\major{  }{}{block}{Sanyo CD-ROM}
+\major{19}{}{char }{Cyclades serial card}
+\major{  }{}{block}{Double compressed disk}
+\major{20}{}{char }{Cyclades serial card -- alternate devices}
+\major{  }{}{block}{Hitachi CD-ROM}
+\major{21}{}{char }{Generic SCSI access}
+\major{22}{}{char }{Digiboard serial card}
+\major{  }{}{block}{Second IDE hard disk/CD-ROM interface}
+\major{23}{}{char }{Digiboard serial card -- alternate devices}
+\major{  }{}{block}{Mitsumi proprietary CD-ROM}
+\major{24}{}{char }{Stallion serial card}
+\major{  }{}{block}{Sony CDU-535 CD-ROM}
+\major{25}{}{char }{Stallion serial card -- alternate devices}
+\major{  }{}{block}{First Matsushita (Panasonic/SoundBlaster) CD-ROM}
+\major{26}{}{char }{Quanta WinVision frame grabber}
+\major{  }{}{block}{Second Matsushita (Panasonic/SoundBlaster) CD-ROM}
+\major{27}{}{char }{QIC-117 tape}
+\major{  }{}{block}{Third Matsushita (Panasonic/SoundBlaster) CD-ROM}
+\major{28}{}{char }{Stallion serial card -- card programming}
+\major{  }{}{char }{Atari SLM ACSI laser printer (68k/Atari)}
+\major{  }{}{block}{Fourth Matsushita (Panasonic/SoundBlaster) CD-ROM}
+\major{  }{}{block}{ACSI disk (68k/Atari)}
+\major{29}{}{char }{Universal frame buffer}
+\major{  }{}{block}{Aztech/Orchid/Okano/Wearnes CD-ROM}
+\major{30}{}{char }{iBCS-2}
+\major{  }{}{block}{Philips LMS-205 CD-ROM}
+\major{31}{}{char }{MPU-401 MIDI}
+\major{  }{}{block}{ROM/flash memory card}
+\major{32}{}{char }{Specialix serial card}
+\major{  }{}{block}{Philips LMS-206 CD-ROM}
+\major{33}{}{char }{Specialix serial card -- alternate devices}
+\major{  }{}{block}{Third IDE hard disk/CD-ROM interface}
+\major{34}{}{char }{Z8530 HDLC driver}
+\major{  }{}{block}{Fourth IDE hard disk/CD-ROM interface}
+\major{35}{}{char }{tclmidi MIDI driver}
+\major{  }{}{block}{Modular RAM disk}
+\major{36}{}{char }{Netlink support}
+\major{  }{}{block}{MCA ESDI hard disk}
+\major{37}{}{char }{IDE tape}
+\major{  }{}{block}{Zorro II ramdisk}
+\major{38}{}{char }{Myricom PCI Myrinet board}
+\major{  }{}{block}{Reserved for Linux/AP+}
+\major{39}{}{char }{ML-16P experimental I/O board}
+\major{  }{}{block}{Reserved for Linux/AP+}
+\major{40}{}{char }{Matrox Meteor frame grabber}
+\major{  }{}{block}{Syquest EZ135 parallel port removable drive}
+\major{41}{}{char }{Yet Another Micro Monitor}
+\major{  }{}{block}{MicroSolutions BackPack parallel port CD-ROM}
+\major{42}{}{}{Demo/sample use}
+\major{43}{}{char }{isdn4linux virtual modem}
+\major{44}{}{char }{isdn4linux virtual modem -- alternate devices}
+\major{45}{}{char }{isdn4linux ISDN BRI driver}
+\major{46}{}{char }{Comtrol Rocketport serial card}
+\major{47}{}{char }{Comtrol Rocketport serial card -- alternate devices}
+\major{48}{}{char }{SDL RISCom serial card}
+\major{49}{}{char }{SDL RISCom serial card -- alternate devices}
+\major{50}{}{char }{Reserved for GLINT}
+\major{51}{}{char }{Baycom radio modem}
+\major{52}{}{char }{Spellcaster DataComm/BRI ISDN card}
+\major{53}{}{char }{BDM interface for remote debugging MC683xx microcontrollers}
+\major{54}{}{char }{Electrocardiognosis Holter serial card}
+\major{55}{}{char }{DSP56001 digital signal processor}
+\major{56}{}{char }{Apple Desktop Bus}
+\major{57}{}{char }{Hayes ESP serial card}
+\major{58}{}{char }{Hayes ESP serial card -- alternate devices}
+\major{59}{}{char }{sf firewall package}
+\major{60}{--63}{}{Local/experimental use}
+\major{64}{--119}{}{Unallocated}
+\major{120}{--127}{}{Local/experimental use}
+\major{128}{--239}{}{Unallocated}
+\major{240}{--254}{}{Local/experimental use}
+\major{255}{}{}{Reserved}
+\end{devicelist}
+
+\section{Minor numbers}
+
+
+\begin{devicelist}
+\major{0}{}{}{Unnamed devices (e.g. non-device mounts)}
+	\minor{0}{}{reserved as null device number}
+\end{devicelist}
+
+\begin{devicelist}
+\major{1}{}{char}{Memory devices}
+	\minor{1}{/dev/mem}{Physical memory access}
+	\minor{2}{/dev/kmem}{Kernel virtual memory access}
+	\minor{3}{/dev/null}{Null device}
+	\minor{4}{/dev/port}{I/O port access}
+	\minor{5}{/dev/zero}{Null byte source}
+	\minor{6}{/dev/core}{OBSOLETE -- should be a link to {\file /proc/kcore}}
+	\minor{7}{/dev/full}{Returns ENOSPC on write}
+	\minor{8}{/dev/random}{Nondeterministic random number generator}
+	\minor{9}{/dev/urandom}{Less secure, but faster random number generator}
+\\
+\major{}{}{block}{RAM disk}
+	\minor{0}{/dev/ram0}{First RAM disk}
+	\minordots
+	\minor{7}{/dev/ram7}{Eighth RAM disk}
+	\minor{250}{/dev/initrd}{Initial RAM disk}
+\end{devicelist}
+
+\noindent
+Earlier kernels had {\file /dev/ramdisk} (1, 1) here.  {\file /dev/initrd}
+refers to a RAM disk which was preloaded by the boot loader.
+
+\begin{devicelist}
+\major{2}{}{char}{Pseudo-TTY masters}
+	\minor{0}{/dev/ptyp0}{First PTY master}
+	\minor{1}{/dev/ptyp1}{Second PTY master}
+	\minordots
+	\minor{255}{/dev/ptyef}{256th PTY master}
+\end{devicelist}
+
+\noindent
+Pseudo-TTY's are named as follows:
+\begin{itemize}
+\item Masters are {\file pty}, slaves are {\file tty};
+\item the fourth letter is one of {\file pqrstuvwxyzabcde} indicating
+the 1st through 16th series of 16 pseudo-ttys each, and
+\item the fifth letter is one of {\file 0123456789abcdef} indicating
+the position within the series.
+\end{itemize}
+
+\begin{devicelist}
+\major{}{}{block}{Floppy disks}
+	\minor{0}{/dev/fd0}{Controller 1, drive 1 autodetect}
+	\minor{1}{/dev/fd1}{Controller 1, drive 2 autodetect}
+	\minor{2}{/dev/fd2}{Controller 1, drive 3 autodetect}
+	\minor{3}{/dev/fd3}{Controller 1, drive 4 autodetect}
+	\minor{128}{/dev/fd4}{Controller 2, drive 1 autodetect}
+	\minor{129}{/dev/fd5}{Controller 2, drive 2 autodetect}
+	\minor{130}{/dev/fd6}{Controller 2, drive 3 autodetect}
+	\minor{131}{/dev/fd7}{Controller 2, drive 4 autodetect}
+\\
+\major{}{}{}{To specify format, add to the autodetect device number}
+	\minor{  0}{/dev/fd?}{Autodetect format}
+	\minor{  4}{/dev/fd?d360}{5.25" \num{4}{360}K in a \num{4}{360}K drive\1}
+	\minor{ 20}{/dev/fd?h360}{5.25" \num{4}{360}K in a 1200K drive\1}
+	\minor{ 48}{/dev/fd?h410}{5.25" \num{4}{410}K in a 1200K drive}
+	\minor{ 64}{/dev/fd?h420}{5.25" \num{4}{420}K in a 1200K drive}
+	\minor{ 24}{/dev/fd?h720}{5.25" \num{4}{720}K in a 1200K drive}
+	\minor{ 80}{/dev/fd?h880}{5.25" \num{4}{880}K in a 1200K drive\1}
+	\minor{  8}{/dev/fd?h1200}{5.25" 1200K in a 1200K drive\1}
+	\minor{ 40}{/dev/fd?h1440}{5.25" 1440K in a 1200K drive\1}
+	\minor{ 56}{/dev/fd?h1476}{5.25" 1476K in a 1200K drive}
+	\minor{ 72}{/dev/fd?h1494}{5.25" 1494K in a 1200K drive}
+	\minor{ 92}{/dev/fd?h1600}{5.25" 1600K in a 1200K drive\1}
+	\minor{}{}{}
+	\minor{ 12}{/dev/fd?u360}{3.5" \num{4}{360}K Double Density}
+	\minor{ 16}{/dev/fd?u720}{3.5" \num{4}{720}K Double Density\1}
+	\minor{120}{/dev/fd?u800}{3.5" \num{4}{800}K Double Density\2}
+	\minor{ 52}{/dev/fd?u820}{3.5" \num{4}{820}K Double Density}
+	\minor{ 68}{/dev/fd?u830}{3.5" \num{4}{830}K Double Density}
+	\minor{ 84}{/dev/fd?u1040}{3.5" 1040K Double Density\1}
+	\minor{ 88}{/dev/fd?u1120}{3.5" 1120K Double Density\1}
+	\minor{ 28}{/dev/fd?u1440}{3.5" 1440K High Density\1}
+	\minor{124}{/dev/fd?u1600}{3.5" 1600K High Density\1}
+	\minor{ 44}{/dev/fd?u1680}{3.5" 1680K High Density\3}
+	\minor{ 60}{/dev/fd?u1722}{3.5" 1722K High Density}
+	\minor{ 76}{/dev/fd?u1743}{3.5" 1743K High Density}
+	\minor{ 96}{/dev/fd?u1760}{3.5" 1760K High Density}
+	\minor{116}{/dev/fd?u1840}{3.5" 1840K High Density\3}
+	\minor{100}{/dev/fd?u1920}{3.5" 1920K High Density\1}
+	\minor{ 32}{/dev/fd?u2880}{3.5" 2880K Extra Density\1}
+	\minor{104}{/dev/fd?u3200}{3.5" 3200K Extra Density}
+	\minor{108}{/dev/fd?u3520}{3.5" 3520K Extra Density}
+	\minor{112}{/dev/fd?u3840}{3.5" 3840K Extra Density\1}
+	\minor{}{}{}
+	\minor{36}{/dev/fd?CompaQ}{Compaq 2880K drive; probably obsolete}
+\\
+\major{}{}{}{\1 Autodetectable format}
+\major{}{}{}{\2 Autodetectable format in a Double Density (720K) drive only}
+\major{}{}{}{\3 Autodetectable format in a High Density (1440K) drive only}
+\end{devicelist}
+
+NOTE: The letter in the device name ({\file d}, {\file q}, {\file h}
+or {\file u}) signifies the type of drive supported: 5.25" Double
+Density ({\file d}), 5.25" Quad Density ({\file q}), 5.25" High
+Density ({\file h}) or 3.5" (any type, {\file u}).  The capital
+letters {\file D}, {\file H}, or {\file E} for the 3.5" models have
+been deprecated, since the drive type is insignificant for these devices.
+
+\begin{devicelist}
+\major{3}{}{char}{Pseudo-TTY slaves}
+	\minor{0}{/dev/ttyp0}{First PTY slave}
+	\minor{1}{/dev/ttyp1}{Second PTY slave}
+	\minordots
+	\minor{255}{/dev/ttyef}{256th PTY slave}
+\\
+\major{}{}{block}{First MFM, RLL and IDE hard disk/CD-ROM interface}
+	\minor{0}{/dev/hda}{Master: whole disk (or CD-ROM)}
+	\minor{64}{/dev/hdb}{Slave: whole disk (or CD-ROM)}
+\\
+\major{}{}{}{For partitions, add to the whole disk device number}
+	\minor{0}{/dev/hd?}{Whole disk}
+	\minor{1}{/dev/hd?1}{First partition}
+	\minor{2}{/dev/hd?2}{Second partition}
+	\minordots
+	\minor{63}{/dev/hd?63}{63rd partition}
+\end{devicelist}
+
+\noindent
+For Linux/i386, partitions 1-4 are the primary partitions, partitions
+5 and up are logical partitions.  Other versions of Linux use
+partitioning schemes appropriate to their respective architectures.
+
+\begin{devicelist}
+\major{ 4}{}{char }{TTY devices}
+	\minor{0}{/dev/console}{Console device}
+	\minor{1}{/dev/tty1}{First virtual console}
+	\minordots
+	\minor{63}{/dev/tty63}{63rd virtual console}
+	\minor{64}{/dev/ttyS0}{First serial port}
+	\minordots
+	\minor{127}{/dev/ttyS63}{64th serial port}
+	\minor{128}{/dev/ptyp0}{First pseudo-tty master}
+	\minordots
+	\minor{191}{/dev/ptysf}{64th pseudo-tty master}
+	\minor{192}{/dev/ttyp0}{First pseudo-tty slave}
+	\minordots
+	\minor{255}{/dev/ttysf}{64th pseudo-tty slave}
+\end{devicelist}
+
+\noindent
+For compatibility with previous versions of Linux, the first 64 PTYs
+are replicated under this device number.  This use will be obsolescent
+with the release of Linux 2.0 and may be removed in a future version
+of Linux.
+
+\begin{devicelist}
+\major{ 5}{}{char }{Alternate TTY devices}
+	\minor{0}{/dev/tty}{Current TTY device}
+	\minor{64}{/dev/cua0}{Callout device corresponding to {\file ttyS0}}
+	\minordots
+	\minor{127}{/dev/cua63}{Callout device corresponding to {\file ttyS63}}
+\end{devicelist}
+
+\begin{devicelist}
+\major{ 6}{}{char }{Parallel printer devices}
+	\minor{0}{/dev/lp0}{First parallel printer ({\hex 0x3bc})}
+	\minor{1}{/dev/lp1}{Second parallel printer ({\hex 0x378})}
+	\minor{2}{/dev/lp2}{Third parallel printer ({\hex 0x278})}
+\end{devicelist}
+
+\noindent
+Not all computers have the {\hex 0x3bc} parallel port, hence the
+"first" printer may be either {\file /dev/lp0} or {\file /dev/lp1}.
+
+\begin{devicelist}
+\major{ 7}{}{char }{Virtual console access devices}
+	\minor{0}{/dev/vcs}{Current vc text access}
+	\minor{1}{/dev/vcs1}{tty1 text access}
+	\minordots
+	\minor{63}{/dev/vcs63}{tty63 text access}
+	\minor{128}{/dev/vcsa}{Current vc text/attribute access}
+	\minor{129}{/dev/vcsa1}{tty1 text/attribute access}
+	\minordots
+	\minor{191}{/dev/vcsa63}{tty63 text/attribute access}
+\end{devicelist}
+
+\noindent
+NOTE: These devices permit both read and write access.
+
+\begin{devicelist}
+\major{  }{}{block}{Loopback devices}
+	\minor{0}{/dev/loop0}{First loopback device}
+	\minor{1}{/dev/loop1}{Second loopback device}
+	\minordots
+\end{devicelist}
+
+\begin{devicelist}
+\major{ 8}{}{block}{SCSI disk devices}
+	\minor{0}{/dev/sda}{First SCSI disk whole disk}
+	\minor{16}{/dev/sdb}{Second SCSI disk whole disk}
+	\minor{32}{/dev/sdc}{Third SCSI disk whole disk}
+	\minordots
+	\minor{240}{/dev/sdp}{Sixteenth SCSI disk whole disk}
+\end{devicelist}
+
+\noindent
+Partitions are handled in the same way as for IDE disks (see major
+number 3) except that the partition limit is 15 rather than 63 per
+disk.
+
+\begin{devicelist}
+\major{ 9}{}{char }{SCSI tape devices}
+	\minor{0}{/dev/st0}{First SCSI tape, mode 0}
+	\minor{1}{/dev/st1}{Second SCSI tape, mode 0}
+	\minordots
+	\minor{32}{/dev/st0l}{First SCSI tape, mode 1}
+	\minor{33}{/dev/st1l}{Second SCSI tape, mode 1}
+	\minordots
+	\minor{64}{/dev/st0m}{First SCSI tape, mode 2}
+	\minor{65}{/dev/st1m}{Second SCSI tape, mode 2}
+	\minordots
+	\minor{96}{/dev/st0a}{First SCSI tape, mode 3}
+	\minor{97}{/dev/st1a}{Second SCSI tape, mode 4}
+	\minordots
+	\minor{128}{/dev/nst0}{First SCSI tape, mode 0, no rewind}
+	\minor{129}{/dev/nst1}{Second SCSI tape, mode 0, no rewind}
+	\minordots
+	\minor{160}{/dev/nst0l}{First SCSI tape, mode 1, no rewind}
+	\minor{161}{/dev/nst1l}{Second SCSI tape, mode 1, no rewind}
+	\minordots
+	\minor{192}{/dev/nst0m}{First SCSI tape, mode 2, no rewind}
+	\minor{193}{/dev/nst1m}{Second SCSI tape, mode 2, no rewind}
+	\minordots
+	\minor{224}{/dev/nst0a}{First SCSI tape, mode 3, no rewind}
+	\minor{225}{/dev/nst1a}{Second SCSI tape, mode 3, no rewind}
+	\minordots
+\end{devicelist}
+
+\noindent
+``No rewind'' refers to the omission of the default automatic rewind
+on device close.  The {\file MTREW} or {\file MTOFFL} ioctl()s can be
+used to rewind the tape regardless of the device used to access it.
+
+\begin{devicelist}
+\major{  }{}{block}{Metadisk (RAID) devices}
+	\minor{0}{/dev/md0}{First metadisk group}
+	\minor{1}{/dev/md1}{Second metadisk group}
+	\minordots
+\end{devicelist}
+
+\noindent
+The metadisk driver is used to span a filesystem across multiple
+physical disks.
+
+\begin{devicelist}
+\major{10}{}{char }{Non-serial mice, misc features}
+	\minor{0}{/dev/logibm}{Logitech bus mouse}
+	\minor{1}{/dev/psaux}{PS/2-style mouse port}
+	\minor{2}{/dev/inportbm}{Microsoft Inport bus mouse}
+	\minor{3}{/dev/atibm}{ATI XL bus mouse}
+	\minor{4}{/dev/jbm}{J-mouse}
+	\minor{4}{/dev/amigamouse}{Amiga mouse (68k/Amiga)}
+	\minor{5}{/dev/atarimouse}{Atari mouse}
+	\minor{6}{/dev/sunmouse}{Sun mouse}
+	\minor{7}{/dev/amigamouse1}{Second Amiga mouse}
+	\minor{8}{/dev/smouse}{Simple serial mouse driver}
+	\minor{128}{/dev/beep}{Fancy beep device}
+	\minor{129}{/dev/modreq}{Kernel module load request}
+	\minor{130}{/dev/watchdog}{Watchdog timer port}
+	\minor{131}{/dev/temperature}{Machine internal temperature}
+	\minor{132}{/dev/hwtrap}{Hardware fault trap}
+	\minor{133}{/dev/exttrp}{External device trap}
+	\minor{134}{/dev/apm\_bios}{Advanced Power Management BIOS}
+	\minor{135}{/dev/rtc}{Real Time Clock}
+	\minor{136}{/dev/qcam0}{QuickCam on {\file lp0}}
+	\minor{137}{/dev/qcam1}{QuickCam on {\file lp1}}
+	\minor{138}{/dev/qcam2}{QuickCam on {\file lp2}}
+	\minor{139}{/dev/openprom}{SPARC OpenBoot PROM}
+\end{devicelist}
+
+\noindent
+The loopback devices are used to mount filesystems not associated with
+block devices.  The binding to the loopback devices is usually handled
+by {\bf mount}(8).
+
+\begin{devicelist}
+\major{11}{}{char }{Raw keyboard device}
+	\minor{0}{/dev/kbd}{Raw keyboard device}
+\end{devicelist}
+
+\noindent
+The raw keyboard device is used on Linux/SPARC only.
+
+\begin{devicelist}
+\major{  }{}{block}{SCSI CD-ROM devices}
+	\minor{0}{/dev/sr0}{First SCSI CD-ROM}
+	\minor{1}{/dev/sr1}{Second SCSI CD-ROM}
+	\minordots
+\end{devicelist}
+
+\noindent
+The prefix {\file /dev/scd} instead of {\file /dev/sr} has been used
+as well, and might make more sense.
+
+\begin{devicelist}
+\major{12}{}{char }{QIC-02 tape}
+	\minor{2}{/dev/ntpqic11}{QIC-11, no rewind-on-close}
+	\minor{3}{/dev/tpqic11}{QIC-11, rewind-on-close}
+	\minor{4}{/dev/ntpqic24}{QIC-24, no rewind-on-close}
+	\minor{5}{/dev/tpqic24}{QIC-24, rewind-on-close}
+	\minor{6}{/dev/ntpqic120}{QIC-120, no rewind-on-close}
+	\minor{7}{/dev/tpqic120}{QIC-120, rewind-on-close}
+	\minor{8}{/dev/ntpqic150}{QIC-150, no rewind-on-close}
+	\minor{9}{/dev/tpqic150}{QIC-150, rewind-on-close}
+\end{devicelist}
+
+\noindent
+The device names specified are proposed -- if there are ``standard''
+names for these devices, please let me know.
+
+\begin{devicelist}
+\major{  }{}{block}{MSCDEX CD-ROM callback support}
+	\minor{0}{/dev/dos\_cd0}{First MSCDEX CD-ROM}
+	\minor{1}{/dev/dos\_cd1}{Second MSCDEX CD-ROM}
+	\minordots
+\end{devicelist}
+
+\begin{devicelist}
+\major{13}{}{char }{PC speaker}
+	\minor{0}{/dev/pcmixer}{Emulates {\file /dev/mixer}}
+	\minor{3}{/dev/pcsp}{Emulates {\file /dev/dsp} (8-bit)}
+	\minor{4}{/dev/pcaudio}{Emulates {\file /dev/audio}}
+	\minor{5}{/dev/pcsp16}{Emulates {\file /dev/dsp} (16-bit)}
+\\
+\major{  }{}{block}{8-bit MFM/RLL/IDE controller}
+	\minor{0}{/dev/xda}{First XT disk whole disk}
+	\minor{64}{/dev/xdb}{Second XT disk whole disk}
+\end{devicelist}
+
+\noindent
+Partitions are handled in the same way as for IDE disks (see major
+number 3).
+
+\begin{devicelist}
+\major{14}{}{char }{Sound card}
+	\minor{0}{/dev/mixer}{Mixer control}
+	\minor{1}{/dev/sequencer}{Audio sequencer}
+	\minor{2}{/dev/midi00}{First MIDI port}
+	\minor{3}{/dev/dsp}{Digital audio}
+	\minor{4}{/dev/audio}{Sun-compatible digital audio}
+	\minor{6}{/dev/sndstat}{Sound card status information}
+	\minor{8}{/dev/sequencer2}{Sequencer -- alternate device}
+	\minor{16}{/dev/mixer1}{Second soundcard mixer control}
+	\minor{17}{/dev/patmgr0}{Sequencer patch manager}
+	\minor{18}{/dev/midi01}{Second MIDI port}
+	\minor{19}{/dev/dsp1}{Second soundcard digital audio}
+	\minor{20}{/dev/audio1}{Second soundcard Sun digital audio}
+	\minor{33}{/dev/patmgr1}{Sequencer patch manager}
+	\minor{34}{/dev/midi02}{Third MIDI port}
+	\minor{50}{/dev/midi03}{Fourth MIDI port}
+\\
+\major{  }{}{block}{BIOS harddrive callback support}
+	\minor{0}{/dev/dos\_hda}{First BIOS harddrive whole disk}
+	\minor{64}{/dev/dos\_hdb}{Second BIOS harddrive whole disk}
+	\minor{128}{/dev/dos\_hdc}{Third BIOS harddrive whole disk}
+	\minor{192}{/dev/dos\_hdd}{Fourth BIOS harddrive whole disk}
+\end{devicelist}
+
+\noindent
+Partitions are handled in the same way as for IDE disks (see major
+number 3).
+
+\begin{devicelist}
+\major{15}{}{char }{Joystick}
+	\minor{0}{/dev/js0}{First analog joystick}
+	\minor{1}{/dev/js1}{Second analog joystick}
+	\minordots
+	\minor{128}{/dev/djs0}{First digital joystick}
+	\minor{129}{/dev/djs1}{Second digital joystick}
+	\minordots
+\\
+\major{  }{}{block}{Sony CDU-31A/CDU-33A CD-ROM}
+	\minor{0}{/dev/sonycd}{Sony CDU-31A CD-ROM}
+\end{devicelist}
+
+\begin{devicelist}
+\major{16}{}{char }{Non-SCSI scanners}
+	\minor{0}{/dev/gs4500}{Genius 4500 handheld scanner}
+\\
+\major{  }{}{block}{GoldStar CD-ROM}
+	\minor{0}{/dev/gscd}{GoldStar CD-ROM}
+\end{devicelist}
+
+\begin{devicelist}
+\major{17}{}{char }{Chase serial card}
+	\minor{0}{/dev/ttyH0}{First Chase port}
+	\minor{1}{/dev/ttyH1}{Second Chase port}
+	\minordots
+\\
+\major{  }{}{block}{Optics Storage CD-ROM}
+	\minor{0}{/dev/optcd}{Optics Storage CD-ROM}
+\end{devicelist}
+
+\begin{devicelist}
+\major{18}{}{char }{Chase serial card -- alternate devices}
+	\minor{0}{/dev/cuh0}{Callout device corresponding to {\file ttyH0}}
+	\minor{1}{/dev/cuh1}{Callout device corresponding to {\file ttyH1}}
+	\minordots
+\\
+\major{  }{}{block}{Sanyo CD-ROM}
+	\minor{0}{/dev/sjcd}{Sanyo CD-ROM}
+\end{devicelist}
+
+\begin{devicelist}
+\major{19}{}{char }{Cyclades serial card}
+	\minor{0}{/dev/ttyC0}{First Cyclades port}
+	\minordots
+	\minor{31}{/dev/ttyC31}{32nd Cyclades port}
+\\
+\major{  }{}{block}{``Double'' compressed disk}
+	\minor{0}{/dev/double0}{First compressed disk}
+	\minordots
+	\minor{7}{/dev/double7}{Eighth compressed disk}
+	\minor{128}{/dev/cdouble0}{Mirror of first compressed disk}
+	\minordots
+	\minor{135}{/dev/cdouble7}{Mirror of eighth compressed disk}
+\end{devicelist}
+
+\noindent
+See the Double documentation for an explanation of the ``mirror'' devices.
+
+\begin{devicelist}
+\major{20}{}{char }{Cyclades serial card -- alternate devices}
+	\minor{0}{/dev/cub0}{Callout device corresponding to {\file ttyC0}}
+	\minordots
+	\minor{31}{/dev/cub31}{Callout device corresponding to {\file ttyC31}}
+\\
+\major{  }{}{block}{Hitachi CD-ROM}
+	\minor{0}{/dev/hitcd}{Hitachi CD-ROM}
+\end{devicelist}
+
+\begin{devicelist}
+\major{21}{}{char }{Generic SCSI access}
+	\minor{0}{/dev/sg0}{First generic SCSI device}
+	\minor{1}{/dev/sg1}{Second generic SCSI device}
+	\minordots
+\end{devicelist}
+
+\begin{devicelist}
+\major{22}{}{char }{Digiboard serial card}
+	\minor{0}{/dev/ttyD0}{First Digiboard port}
+	\minor{1}{/dev/ttyD1}{Second Digiboard port}
+	\minordots
+\major{  }{}{block}{Second IDE hard disk/CD-ROM interface}
+	\minor{0}{/dev/hdc}{Master: whole disk (or CD-ROM)}
+	\minor{64}{/dev/hdd}{Slave: whole disk (or CD-ROM)}
+\end{devicelist}
+
+\noindent
+Partitions are handled the same way as for the first interface (see
+major number 3).
+
+\begin{devicelist}
+\major{23}{}{char }{Digiboard serial card -- alternate devices}
+	\minor{0}{/dev/cud0}{Callout device corresponding to {\file ttyD0}}
+	\minor{1}{/dev/cud1}{Callout device corresponding to {\file ttyD1}}
+	\minordots
+\major{  }{}{block}{Mitsumi proprietary CD-ROM}
+	\minor{0}{/dev/mcd}{Mitsumi CD-ROM}
+\end{devicelist}
+
+\begin{devicelist}\
+\major{24}{}{char }{Stallion serial card}
+	\minor{0}{/dev/ttyE0}{Stallion port 0 board 0}
+	\minor{1}{/dev/ttyE1}{Stallion port 1 board 0}
+	\minordots
+	\minor{64}{/dev/ttyE64}{Stallion port 0 board 1}
+	\minor{65}{/dev/ttyE65}{Stallion port 1 board 1}
+	\minordots
+	\minor{128}{/dev/ttyE128}{Stallion port 0 board 2}
+	\minor{129}{/dev/ttyE129}{Stallion port 1 board 2}
+	\minordots
+	\minor{192}{/dev/ttyE192}{Stallion port 0 board 3}
+	\minor{193}{/dev/ttyE193}{Stallion port 1 board 3}
+	\minordots
+\\
+\major{  }{}{block}{Sony CDU-535 CD-ROM}
+	\minor{0}{/dev/cdu535}{Sony CDU-535 CD-ROM}
+\end{devicelist}
+
+\begin{devicelist}
+\major{25}{}{char }{Stallion serial card -- alternate devices}
+	\minor{0}{/dev/cue0}{Callout device corresponding to {\file ttyE0}}
+	\minor{1}{/dev/cue1}{Callout device corresponding to {\file ttyE1}}
+	\minordots
+	\minor{64}{/dev/cue64}{Callout device corresponding to {\file ttyE64}}
+	\minor{65}{/dev/cue65}{Callout device corresponding to {\file ttyE65}}
+	\minordots
+	\minor{128}{/dev/cue128}{Callout device corresponding to {\file ttyE128}}
+	\minor{129}{/dev/cue129}{Callout device corresponding to {\file ttyE129}}
+	\minordots
+	\minor{192}{/dev/cue192}{Callout device corresponding to {\file ttyE192}}
+	\minor{193}{/dev/cue193}{Callout device corresponding to {\file ttyE193}}
+	\minordots
+\\
+\major{  }{}{block}{First Matsushita (Panasonic/SoundBlaster) CD-ROM}
+	\minor{0}{/dev/sbpcd0}{Panasonic CD-ROM controller 0 unit 0}
+	\minor{1}{/dev/sbpcd1}{Panasonic CD-ROM controller 0 unit 1}
+	\minor{2}{/dev/sbpcd2}{Panasonic CD-ROM controller 0 unit 2}
+	\minor{3}{/dev/sbpcd3}{Panasonic CD-ROM controller 0 unit 3}
+\end{devicelist}
+
+\begin{devicelist}
+\major{26}{}{char }{Quanta WinVision frame grabber}
+	\minor{0}{/dev/wvisfgrab}{Quanta WinVision frame grabber}
+\\
+\major{  }{}{block}{Second Matsushita (Panasonic/SoundBlaster) CD-ROM}
+	\minor{0}{/dev/sbpcd4}{Panasonic CD-ROM controller 1 unit 0}
+	\minor{1}{/dev/sbpcd5}{Panasonic CD-ROM controller 1 unit 1}
+	\minor{2}{/dev/sbpcd6}{Panasonic CD-ROM controller 1 unit 2}
+	\minor{3}{/dev/sbpcd7}{Panasonic CD-ROM controller 1 unit 3}
+\end{devicelist}
+
+\begin{devicelist}
+\major{27}{}{char }{QIC-117 tape}
+	\minor{0}{/dev/rft0}{Unit 0, rewind-on-close}
+	\minor{1}{/dev/rft1}{Unit 1, rewind-on-close}
+	\minor{2}{/dev/rft2}{Unit 2, rewind-on-close}
+	\minor{3}{/dev/rft3}{Unit 3, rewind-on-close}
+	\minor{4}{/dev/nrft0}{Unit 0, no rewind-on-close}
+	\minor{5}{/dev/nrft1}{Unit 1, no rewind-on-close}
+	\minor{6}{/dev/nrft2}{Unit 2, no rewind-on-close}
+	\minor{7}{/dev/nrft3}{Unit 3, no rewind-on-close}
+\\
+\major{  }{}{block}{Third Matsushita (Panasonic/SoundBlaster) CD-ROM}
+	\minor{0}{/dev/sbpcd8}{Panasonic CD-ROM controller 2 unit 0}
+	\minor{1}{/dev/sbpcd9}{Panasonic CD-ROM controller 2 unit 1}
+	\minor{2}{/dev/sbpcd10}{Panasonic CD-ROM controller 2 unit 2}
+	\minor{3}{/dev/sbpcd11}{Panasonic CD-ROM controller 2 unit 3}
+\end{devicelist}
+
+\begin{devicelist}
+\major{28}{}{char }{Stallion serial card -- card programming}
+	\minor{0}{/dev/staliomem0}{First Stallion I/O card memory}
+	\minor{1}{/dev/staliomem1}{Second Stallion I/O card memory}
+	\minor{2}{/dev/staliomem2}{Third Stallion I/O card memory}
+	\minor{3}{/dev/staliomem3}{Fourth Stallion I/O card memory}
+\\
+\major{  }{}{char }{Atari SLM ACSI laser printer (68k/Atari)}
+	\minor{0}{/dev/slm0}{First SLM laser printer}
+	\minor{1}{/dev/slm1}{Second SLM laser printer}
+	\minordots
+\\
+\major{  }{}{block}{Fourth Matsushita (Panasonic/SoundBlaster) CD-ROM}
+	\minor{0}{/dev/sbpcd12}{Panasonic CD-ROM controller 3 unit 0}
+	\minor{1}{/dev/sbpcd13}{Panasonic CD-ROM controller 3 unit 1}
+	\minor{2}{/dev/sbpcd14}{Panasonic CD-ROM controller 3 unit 2}
+	\minor{3}{/dev/sbpcd15}{Panasonic CD-ROM controller 3 unit 3}
+\\
+\major{  }{}{block}{ACSI disk/CD-ROM (68k/Atari)}
+	\minor{0}{/dev/ada}{First ACSI disk whole disk}
+	\minor{16}{/dev/adb}{Second ACSI disk whole disk}
+	\minor{32}{/dev/adc}{Third ACSI disk whole disk}
+	\minordots
+	\minor{240}{/dev/adp}{Sixteenth ACSI disk whole disk}
+\end{devicelist}
+
+\noindent
+Partitions are handled in the same way as for IDE disks (see major
+number 3) except that the partition limit is 15 rather than 63 per
+disk (same as SCSI.)
+
+\begin{devicelist}
+\major{29}{}{char }{Universal frame buffer}
+	\minor{0}{/dev/fb0}{First frame buffer}
+	\minor{1}{/dev/fb0autodetect}{}
+	\minor{24}{/dev/fb0user0}{}
+	\minordots
+	\minor{31}{/dev/fb0user7}{}
+	\minor{32}{/dev/fb1}{Second frame buffer}
+	\minor{33}{/dev/fb1autodetect}{}
+	\minor{56}{/dev/fb1user0}{}
+	\minordots
+	\minor{63}{/dev/fb1user7}{}
+	\minordots
+\end{devicelist}
+
+\noindent
+The universal frame buffer device is currently supported only on
+Linux/68k and Linux/SPARC.  The plain device accesses the frame
+buffer at current resolution (Linux/68k calls this file {\file
+current}, e.g. {\file /dev/fb0current}); the {\file autodetect} one at
+bootup (default) resolution.  Minor numbers 2--23 within each frame
+buffer assignment are used for specific device-dependent resolutions.
+There appears to be no standard naming for these devices.  Finally,
+24--31 within each device are reserved for user-selected modes,
+usually entered at boot time.  Currently only Linux/68k uses the
+mode-specific devices.
+
+\begin{devicelist}
+\major{  }{}{block}{Aztech/Orchid/Okano/Wearnes CD-ROM}
+	\minor{0}{/dev/aztcd}{Aztech CD-ROM}
+\end{devicelist}
+
+\begin{devicelist}
+\major{30}{}{char }{iBCS-2 compatibility devices}
+	\minor{0}{/dev/socksys}{Socket access}
+	\minor{1}{/dev/spx}{SVR3 local X interface}
+	\minor{2}{/dev/inet/arp}{Network access}
+	\minor{2}{/dev/inet/icmp}{Network access}
+	\minor{2}{/dev/inet/ip}{Network access}
+	\minor{2}{/dev/inet/udp}{Network access}
+	\minor{2}{/dev/inet/tcp}{Network access}
+\end{devicelist}
+
+\noindent
+iBCS-2 requires {\file /dev/nfsd} to be a link to {\file /dev/socksys}
+and {\file /dev/X0R} to be a link to {\file /dev/null}.
+
+\begin{devicelist}
+\major{  }{}{block}{Philips LMS CM-205 CD-ROM}
+	\minor{0}{/dev/cm205cd}{Philips LMS CM-205 CD-ROM}
+\end{devicelist}
+
+\noindent
+{\file /dev/lmscd} is an older name for this drive.  This driver does
+not work with the CM-205MS CD-ROM.
+
+\begin{devicelist}
+\major{31}{}{char }{MPU-401 MIDI}
+	\minor{0}{/dev/mpu401data}{MPU-401 data port}
+	\minor{1}{/dev/mpu401stat}{MPU-401 status port}
+\\
+\major{  }{}{block}{ROM/flash memory card}
+	\minor{0}{/dev/rom0}{First ROM card (rw)}
+	\minordots
+	\minor{7}{/dev/rom7}{Eighth ROM card (rw)}
+	\minor{8}{/dev/rrom0}{First ROM card (ro)}
+	\minordots
+	\minor{15}{/dev/rrom0}{Eighth ROM card (ro)}
+	\minor{16}{/dev/flash0}{First flash memory card (rw)}
+	\minordots
+	\minor{23}{/dev/flash7}{Eighth flash memory card (rw)}
+	\minor{24}{/dev/rflash0}{First flash memory card (ro)}
+	\minordots
+	\minor{31}{/dev/rflash7}{Eighth flash memory card (ro)}
+\end{devicelist}
+
+\noindent
+The read-write (rw) devices support back-caching written data in RAM,
+as well as writing to flash RAM devices.  The read-only devices (ro)
+support reading only.
+
+\begin{devicelist}
+\major{32}{}{char }{Specialix serial card}
+	\minor{0}{/dev/ttyX0}{First Specialix port}
+	\minor{1}{/dev/ttyX1}{Second Specialix port}
+	\minordots
+\\
+\major{  }{}{block}{Philips LMS CM-206 CD-ROM}
+	\minor{0}{/dev/cm206cd}{Philips LMS CM-206 CD-ROM}
+\end{devicelist}
+
+\begin{devicelist}
+\major{33}{}{char }{Specialix serial card -- alternate devices}
+	\minor{0}{/dev/cux0}{Callout device corresponding to {\file ttyX0}}
+	\minor{1}{/dev/cux1}{Callout device corresponding to {\file ttyX1}}
+	\minordots
+\\
+\major{  }{}{block}{Third IDE hard disk/CD-ROM interface}
+	\minor{0}{/dev/hde}{Master: whole disk (or CD-ROM)}
+	\minor{64}{/dev/hdf}{Slave: whole disk (or CD-ROM)}
+\end{devicelist}
+
+\noindent
+Partitions are handled the same way as for the first interface (see
+major number 3).
+
+\begin{devicelist}
+\major{34}{}{char }{Z8530 HDLC driver}
+	\minor{0}{/dev/scc0}{First Z8530, first port}
+	\minor{1}{/dev/scc1}{First Z8530, second port}
+	\minor{2}{/dev/scc2}{Second Z8530, first port}
+	\minor{3}{/dev/scc3}{Second Z8530, second port}
+	\minordots
+\end{devicelist}
+
+\noindent
+In a previous version these devices were named {\file /dev/sc1} for
+{\file /dev/scc0}, {\file /dev/sc2} for {\file /dev/scc1}, and so on.
+
+\begin{devicelist}
+\major{  }{}{block}{Fourth IDE hard disk/CD-ROM interface}
+	\minor{0}{/dev/hdg}{Master: whole disk (or CD-ROM)}
+	\minor{64}{/dev/hdh}{Slave: whole disk (or CD-ROM)}
+\end{devicelist}
+
+\noindent
+Partitions are handled the same way as for the first interface (see
+major number 3).
+
+\begin{devicelist}
+\major{35}{}{char }{tclmidi MIDI driver}
+	\minor{0}{/dev/midi0}{First MIDI port, kernel timed}
+	\minor{1}{/dev/midi1}{Second MIDI port, kernel timed}
+	\minor{2}{/dev/midi2}{Third MIDI port, kernel timed}
+	\minor{3}{/dev/midi3}{Fourth MIDI port, kernel timed}
+	\minor{64}{/dev/rmidi0}{First MIDI port, untimed}
+	\minor{65}{/dev/rmidi1}{Second MIDI port, untimed}
+	\minor{66}{/dev/rmidi2}{Third MIDI port, untimed}
+	\minor{67}{/dev/rmidi3}{Fourth MIDI port, untimed}
+	\minor{128}{/dev/smpte0}{First MIDI port, SMPTE timed}
+	\minor{129}{/dev/smpte1}{Second MIDI port, SMPTE timed}
+	\minor{130}{/dev/smpte2}{Third MIDI port, SMPTE timed}
+	\minor{131}{/dev/smpte3}{Fourth MIDI port, SMPTE timed}
+\\
+\major{  }{}{block}{Modular RAM disk}
+\end{devicelist}
+
+\noindent
+This device number is provided for older kernels which did not have
+the modular RAM disk in the standard distribution.  See major number
+1.  This assignment will be removed when the 2.0 kernel is released.
+
+\begin{devicelist}
+\major{36}{}{char }{Netlink support}
+	\minor{0}{/dev/route}{Routing, device updates (kernel to user)}
+	\minor{1}{/dev/skip}{enSKIP security cache control}
+\\
+\major{  }{}{block}{MCA ESDI hard disk}
+	\minor{0}{/dev/eda}{First ESDI disk whole disk}
+	\minor{64}{/dev/edb}{Second ESDI disk whole disk}
+	\minordots
+\end{devicelist}
+
+\noindent
+Partitions are handled the same way as for IDE disks (see major number
+3).
+
+\begin{devicelist}
+\major{37}{}{char }{IDE tape}
+	\minor{0}{/dev/ht0}{First IDE tape}
+	\minor{128}{/dev/nht0}{First IDE tape, no rewind-on-close}
+\end{devicelist}
+
+\noindent
+Currently, only one IDE tape drive is supported.
+
+\begin{devicelist}
+\major{  }{}{block}{Zorro II ramdisk}
+	\minor{0}{/dev/z2ram}{Zorro II ramdisk}
+\end{devicelist}
+
+\begin{devicelist}
+\major{38}{}{char }{Myricom PCI Myrinet board}
+	\minor{0}{/dev/mlanai0}{First Myrinet board}
+	\minor{1}{/dev/mlanai1}{Second Myrinet board}
+	\minordots
+\end{devicelist}
+
+\noindent
+This device is used for board control, status query and ``user level
+packet I/O''.  The board is also accessible as a regular {\file eth}
+networking device.
+
+\begin{devicelist}
+\major{  }{}{block}{Reserved for Linux/AP+}
+\end{devicelist}
+
+\begin{devicelist}
+\major{39}{}{char }{ML-16P experimental I/O board}
+	\minor{0}{/dev/ml16pa-a0}{First card, first analog channel}
+	\minor{1}{/dev/ml16pa-a1}{First card, second analog channel}
+	\minordots
+	\minor{15}{/dev/ml16pa-a15}{First card, 16th analog channel}
+	\minor{16}{/dev/ml16pa-d}{First card, digital lines}
+	\minor{17}{/dev/ml16pa-c0}{First card, first counter/timer}
+	\minor{18}{/dev/ml16pa-c1}{First card, second counter/timer}
+	\minor{19}{/dev/ml16pa-c2}{First card, third counter/timer}
+	\minor{32}{/dev/ml16pb-a0}{Second card, first analog channel}
+	\minor{33}{/dev/ml16pb-a1}{Second card, second analog channel}
+	\minordots
+	\minor{47}{/dev/ml16pb-a15}{Second card, 16th analog channel}
+	\minor{48}{/dev/ml16pb-d}{Second card, digital lines}
+	\minor{49}{/dev/ml16pb-c0}{Second card, first counter/timer}
+	\minor{50}{/dev/ml16pb-c1}{Second card, second counter/timer}
+	\minor{51}{/dev/ml16pb-c2}{Second card, third counter/timer}
+	\minordots
+\\
+\major{  }{}{block}{Reserved for Linux/AP+}
+\end{devicelist}
+
+\begin{devicelist}
+\major{40}{}{char }{Matrox Meteor frame grabber}
+	\minor{0}{/dev/mmetfgrab}{Matrox Meteor frame grabber}
+\\
+\major{  }{}{block}{Syquest EZ135 parallel port removable drive}
+	\minor{0}{/dev/eza}{Parallel EZ135 drive whole disk}
+\end{devicelist}
+
+\noindent
+Partitions are handled the same way as for IDE disks (see major number
+3).
+
+\begin{devicelist}
+\major{41}{}{char }{Yet Another Micro Monitor}
+	\minor{0}{/dev/yamm}{Yet Another Micro Monitor}
+\\
+\major{  }{}{block}{MicroSolutions BackPack parallel port CD-ROM}
+	\minor{0}{/dev/bpcd}{BackPack CD-ROM}
+\end{devicelist}
+
+\begin{devicelist}
+\major{42}{}{}{Demo/sample use}
+\end{devicelist}
+
+\noindent
+This number is intended for use in sample code, as well as a general
+``example'' device number.  It should never be used for a device
+driver that is being distributed; either obtain an official number or
+use the local/experimental range.  The sudden addition or removal of a
+driver with this number should not cause ill effects to the system
+(bugs excepted.)
+
+\begin{devicelist}
+\major{43}{}{char }{isdn4linux virtual modem}
+	\minor{0}{/dev/ttyI0}{First virtual modem}
+	\minordots
+	\minor{63}{/dev/ttyI63}{64th virtual modem}
+\end{devicelist}
+
+\begin{devicelist}
+\major{44}{}{char }{isdn4linux virtual modem -- alternate devices}
+	\minor{0}{/dev/cui0}{Callout device corresponding to {\file ttyI0}}
+	\minordots
+	\minor{63}{/dev/cui63}{Callout device corresponding to {\file ttyI63}}
+\end{devicelist}
+
+\begin{devicelist}
+\major{45}{}{char }{isdn4linux ISDN BRI driver}
+	\minor{0}{/dev/isdn0}{First virtual B channel raw data}
+	\minordots
+	\minor{63}{/dev/isdn63}{64th virtual B channel raw data}
+	\minor{64}{/dev/isdnctrl0}{First channel control/debug}
+	\minordots
+	\minor{127}{/dev/isdnctrl63}{64th channel control/debug}
+	\minor{128}{/dev/ippp0}{First SyncPPP device}
+	\minordots
+	\minor{191}{/dev/ippp63}{64th SyncPPP device}
+	\minor{255}{/dev/isdninfo}{ISDN monitor interface}
+\end{devicelist}
+
+\begin{devicelist}
+\major{46}{}{char }{Comtrol Rocketport serial card}
+	\minor{0}{/dev/ttyR0}{First Rocketport port}
+	\minor{1}{/dev/ttyR1}{Second Rocketport port}
+	\minordots
+\end{devicelist}
+
+\begin{devicelist}
+\major{47}{}{char }{Comtrol Rocketport serial card -- alternate devices}
+	\minor{0}{/dev/cur0}{Callout device corresponding to {\file ttyR0}}
+	\minor{1}{/dev/cur1}{Callout device corresponding to {\file ttyR1}}
+	\minordots
+\end{devicelist}
+
+\begin{devicelist}
+\major{48}{}{char }{SDL RISCom serial card}
+	\minor{0}{/dev/ttyL0}{First RISCom port}
+	\minor{1}{/dev/ttyL1}{Second RISCom port}
+	\minordots
+\end{devicelist}
+
+\begin{devicelist}
+\major{49}{}{char }{SDL RISCom serial card -- alternate devices}
+	\minor{0}{/dev/cul0}{Callout device corresponding to {\file ttyL0}}
+	\minor{1}{/dev/cul1}{Callout device corresponding to {\file ttyL1}}
+	\minordots
+\end{devicelist}
+
+\begin{devicelist}
+\major{50}{}{char}{Reserved for GLINT}
+\end{devicelist}
+
+\begin{devicelist}
+\major{51}{}{char }{Baycom radio modem}
+	\minor{0}{/dev/bc0}{First Baycom radio modem}
+	\minor{1}{/dev/bc1}{Second Baycom radio modem}
+	\minordots
+\end{devicelist}
+
+\begin{devicelist}
+\major{52}{}{char }{Spellcaster DataComm/BRI ISDN card}
+	\minor{0}{/dev/dcbri0}{First DataComm card}
+	\minor{1}{/dev/dcbri1}{Second DataComm card}
+	\minor{2}{/dev/dcbri2}{Third DataComm card}
+	\minor{3}{/dev/dcbri3}{Fourth DataComm card}
+\end{devicelist}
+
+\begin{devicelist}
+\major{53}{}{char }{BDM interface for remote debugging MC683xx
+microcontrollers}
+	\minor{0}{/dev/pd\_bdm0}{PD BDM interface on {\file lp0}}
+	\minor{1}{/dev/pd\_bdm1}{PD BDM interface on {\file lp1}}
+	\minor{2}{/dev/pd\_bdm2}{PD BDM interface on {\file lp2}}
+	\minor{4}{/dev/icd\_bdm0}{ICD BDM interface on {\file lp0}}
+	\minor{5}{/dev/icd\_bdm1}{ICD BDM interface on {\file lp1}}
+	\minor{6}{/dev/icd\_bdm2}{ICD BDM interface on {\file lp2}}
+\end{devicelist}
+
+\noindent
+This device is used for the interfacing to the MC683xx
+microcontrollers via Background Debug Mode by use of a Parallel Port
+interface. PD is the Motorola Public Domain Interface and ICD is the
+commercial interface by P\&E.
+
+\begin{devicelist}
+\major{54}{}{char }{Electrocardiognosis Holter serial card}
+	\minor{0}{/dev/holter0}{First Holter port}
+	\minor{1}{/dev/holter1}{Second Holter port}
+	\minor{2}{/dev/holter2}{Third Holter port}
+\end{devicelist}
+
+\noindent
+A custom serial card used by Electrocardiognosis SRL
+$<$mseritan@ottonel.pub.ro$>$ to transfer data from Holter 24-hour
+heart monitoring equipment.
+
+\begin{devicelist}
+\major{55}{}{char }{DSP56001 digital signal processor}
+	\minor{0}{/dev/dsp56k}{First DSP56001}
+\end{devicelist}
+
+\begin{devicelist}
+\major{56}{}{char }{Apple Desktop Bus}
+	\minor{0}{/dev/adb}{ADB bus control}
+\end{devicelist}
+
+\noindent
+Additional devices will be added to this number, all starting with
+{\file /dev/adb}.
+
+\begin{devicelist}
+\major{57}{}{char }{Hayes ESP serial card}
+	\minor{0}{/dev/ttyP0}{First ESP port}
+	\minor{1}{/dev/ttyP1}{Second ESP port}
+	\minordots
+\end{devicelist}
+
+\begin{devicelist}
+\major{58}{}{char }{Hayes ESP serial card -- alternate devices}
+	\minor{0}{/dev/cup0}{Callout device corresponding to {\file ttyP0}}
+	\minor{1}{/dev/cup1}{Callout device corresponding to {\file ttyP1}}
+	\minordots
+\end{devicelist}
+
+\begin{devicelist}
+\major{59}{}{char }{sf firewall package}
+	\minor{0}{/dev/firewall}{Communication with sf kernel module}
+\end{devicelist}
+
+\begin{devicelist}
+\major{60}{--63}{}{Local/experimental use}
+\end{devicelist}
+
+\noindent
+For devices not assigned official numbers, these ranges should be
+used, in order to avoid conflict with future assignments.
+
+\begin{devicelist}
+\major{64}{--119}{}{Unallocated}
+\end{devicelist}
+
+\begin{devicelist}
+\major{120}{--127}{}{Local/experimental use}
+\end{devicelist}
+
+\begin{devicelist}
+\major{128}{--239}{}{Unallocated}
+\end{devicelist}
+
+\begin{devicelist}
+\major{240}{--254}{}{Local/experimental use}
+\end{devicelist}
+
+\begin{devicelist}
+\major{255}{}{}{Reserved}
+\end{devicelist}
+
+\section{Additional /dev directory entries}
+
+This section details additional entries that should or may exist in the
+{\file /dev} directory.  It is preferred that symbolic links use the
+same form (absolute or relative) as is indicated here.  Links are
+classified as {\em hard\/} or {\em symbolic\/} depending on the
+preferred type of link; if possible, the indicated type of link should
+be used.
+
+\subsection{Compulsory links}
+
+These links should exist on all systems:
+
+\begin{nodelist}
+\link{/dev/fd}{/proc/self/fd}{symbolic}{File descriptors}
+\link{/dev/stdin}{fd/0}{symbolic}{Standard input file descriptor}
+\link{/dev/stdout}{fd/1}{symbolic}{Standard output file descriptor}
+\link{/dev/stderr}{fd/2}{symbolic}{Standard error file descriptor}
+\link{/dev/nfsd}{socksys}{symbolic}{Required by iBCS-2}
+\link{/dev/X0R}{null}{symbolic}{Required by iBCS-2}
+\end{nodelist}
+
+\noindent
+Note: The last device is: $<$letter {\tt X}$>$-$<$digit {\tt
+0}$>$-$<$letter {\tt R}$>$.
+
+\subsection{Recommended links}
+
+It is recommended that these links exist on all systems:
+
+\begin{nodelist}
+\link{/dev/core}{/proc/kcore}{symbolic}{Backward compatibility}
+\link{/dev/ramdisk}{ram0}{symbolic}{Backward compatibility}
+\link{/dev/ftape}{rft0}{symbolic}{Backward compatibility}
+\link{/dev/scd?}{sr?}{hard}{Alternate name for CD-ROMs}
+\link{/dev/fd?D*}{fd?u*}{hard}{Backward compatibility}
+\link{/dev/fd?H*}{fd?u*}{hard}{Backward compatibility}
+\link{/dev/fd?E*}{fd?u*}{hard}{Backward compatibility}
+\end{nodelist}
+
+\subsection{Locally defined links}
+
+The following links may be established locally to conform to the
+configuration of the system.  This is merely a tabulation of existing
+practice, and does not constitute a recommendation.  However, if they
+exist, they should have the following uses.
+
+\begin{nodelist}
+\vlink{/dev/mouse}{mouse port}{symbolic}{Current mouse device}
+\vlink{/dev/tape}{tape device}{symbolic}{Current tape device}
+\vlink{/dev/cdrom}{CD-ROM device}{symbolic}{Current CD-ROM device}
+\vlink{/dev/cdwriter}{CD-writer}{symbolic}{Current CD-writer device}
+\vlink{/dev/scanner}{scanner device}{symbolic}{Current scanner device}
+\vlink{/dev/modem}{modem port}{symbolic}{Current dialout device}
+\vlink{/dev/root}{root device}{symbolic}{Current root filesystem}
+\vlink{/dev/swap}{swap device}{symbolic}{Current swap device}
+\end{nodelist}
+
+\noindent
+{\file /dev/modem} should not be used for a modem which supports
+dialin as well as dialout, as it tends to cause lock file problems.
+If it exists, {\file /dev/modem} should point to the appropriate
+dialout (alternate) device.
+
+For SCSI devices, {\file /dev/tape} and {\file /dev/cdrom} should
+point to the ``cooked'' devices ({\file /dev/st*} and {\file
+/dev/sr*}, respectively), whereas {\file /dev/cdwriter} and {\file
+/dev/scanner} should point to the appropriate generic SCSI devices
+({\file /dev/sg*}.)
+
+{\file /dev/mouse} may point to a primary serial TTY device, a
+hardware mouse device, or a socket for a mouse driver program
+(e.g. {\file /dev/gpmdata}.)
+
+\subsection{Sockets and pipes}
+
+Non-transient sockets or named pipes may exist in {\file /dev}.
+Common entries are:
+
+\begin{nodelist}
+\node{/dev/printer}{socket}{{\file lpd} local socket}
+\node{/dev/log}{socket}{{\file syslog} local socket}
+\node{/dev/gpmdata}{socket}{{\file gpm} mouse multiplexer}
+\end{nodelist}
+
+\end{document}
+
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
new file mode 100644
index 000000000..89dc3aaac
--- /dev/null
+++ b/Documentation/devices.txt
@@ -0,0 +1,896 @@
+		       LINUX ALLOCATED DEVICES
+
+	     Maintained by H. Peter Anvin <hpa@zytor.com>
+
+		   Last revised: November 18, 1996
+
+This list is the successor to Rick Miller's Linux Device List, which
+he stopped maintaining when he got busy with other things in 1993.  It
+is a registry of allocated major device numbers, as well as the
+recommended /dev directory nodes for these devices.
+
+The latest version of this list is included with the Linux kernel
+sources in LaTeX and ASCII form.  In case of discrepancy, the LaTeX
+version is authoritative.
+
+This document is included by reference into the Linux Filesystem
+Standard (FSSTND).  The FSSTND is available via FTP from
+tsx-11.mit.edu in the directory /pub/linux/docs/linux-standards/fsstnd.
+
+To have a major number allocated, or a minor number in situations
+where that applies (e.g. busmice), please contact me with the
+appropriate device information.  Also, if you have additional
+information regarding any of the devices listed below, or if I have
+made a mistake, I would greatly appreciate a note.  When sending me
+mail, please include the word "device" in the subject so your mail
+won't accidentally get buried!
+
+Allocations marked (68k/Amiga) apply to Linux/68k on the Amiga
+platform only.  Allocations marked (68k/Atari) apply to Linux/68k on
+the Atari platform only.
+
+This document is in the public domain.  The author requests, however,
+that semantically altered versions are not distributed without
+permission of the author, assuming the author can be contacted without
+an unreasonable effort.
+
+In particular, please don't sent patches for this list to Linus, at
+least not without contacting me first.
+
+I do not have any information about these devices beyond what appears
+on this list.  Any such information requests will be deleted without
+reply.
+
+  0 		Unnamed devices (e.g. non-device mounts)
+		  0 = reserved as null device number
+
+  1 char	Memory devices
+    		  1 = /dev/mem		Physical memory access
+		  2 = /dev/kmem		Kernel virtual memory access
+		  3 = /dev/null		Null device
+		  4 = /dev/port		I/O port access
+		  5 = /dev/zero		Null byte source
+		  6 = /dev/core		OBSOLETE - replaced by /proc/kcore
+		  7 = /dev/full		Returns ENOSPC on write
+		  8 = /dev/random	Nondeterministic random number gen.
+		  9 = /dev/urandom	Faster, less secure random number gen.
+    block	RAM disk
+		  0 = /dev/ram0		First RAM disk
+		    ...
+		  7 = /dev/ram7		Eighth RAM disk
+		250 = /dev/initrd	Initial RAM disk
+
+		Older kernels had /dev/ramdisk (1, 1) here.
+		/dev/initrd refers to a RAM disk which was preloaded
+		by the boot loader.
+		    
+  2 char	Pseudo-TTY masters
+		  0 = /dev/ptyp0	First PTY master
+		  1 = /dev/ptyp1	Second PTY master
+		    ...
+		255 = /dev/ptyef	256th PTY master
+
+		Pseudo-tty's are named as follows:
+		* Masters are "pty", slaves are "tty";
+		* the fourth letter is one of pqrstuvwxyzabcde indicating
+		  the 1st through 16th series of 16 pseudo-ttys each, and
+		* the fifth letter is one of 0123456789abcdef indicating
+		  the position within the series.
+  
+    block	Floppy disks
+		  0 = /dev/fd0		First floppy disk autodetect
+		  1 = /dev/fd1		Second floppy disk autodetect
+		  2 = /dev/fd2		Third floppy disk autodetect
+		  3 = /dev/fd3		Fourth floppy disk autodetect
+
+		To specify format, add to the autodetect device number:
+		  0 = /dev/fd?		Autodetect format
+		  4 = /dev/fd?d360	5.25"  360K in a 360K  drive(1)
+		 20 = /dev/fd?h360	5.25"  360K in a 1200K drive(1)
+		 48 = /dev/fd?h410	5.25"  410K in a 1200K drive
+		 64 = /dev/fd?h420	5.25"  420K in a 1200K drive
+		 24 = /dev/fd?h720	5.25"  720K in a 1200K drive
+		 80 = /dev/fd?h880	5.25"  880K in a 1200K drive(1)
+		  8 = /dev/fd?h1200	5.25" 1200K in a 1200K drive(1)
+		 40 = /dev/fd?h1440	5.25" 1440K in a 1200K drive(1)
+		 56 = /dev/fd?h1476	5.25" 1476K in a 1200K drive
+	  	 72 = /dev/fd?h1494	5.25" 1494K in a 1200K drive
+		 92 = /dev/fd?h1600	5.25" 1600K in a 1200K drive(1)
+
+		 12 = /dev/fd?u360	3.5"   360K Double Density
+		120 = /dev/fd?u800	3.5"   800K Double Density(1)
+		 52 = /dev/fd?u820	3.5"   820K Double Density(2)
+		 68 = /dev/fd?u830	3.5"   830K Double Density
+		 84 = /dev/fd?u1040	3.5"  1040K Double Density(1)
+		 88 = /dev/fd?u1120	3.5"  1120K Double Density(1)
+		 28 = /dev/fd?u1440	3.5"  1440K High Density(1)
+		124 = /dev/fd?u1600	3.5"  1600K High Density(1)
+		 44 = /dev/fd?u1680	3.5"  1680K High Density(3)
+		 60 = /dev/fd?u1722	3.5"  1722K High Density
+		 76 = /dev/fd?u1743	3.5"  1743K High Density
+		 96 = /dev/fd?u1760	3.5"  1760K High Density
+		116 = /dev/fd?u1840	3.5"  1840K High Density(3)
+		100 = /dev/fd?u1920	3.5"  1920K High Density(1)
+		 32 = /dev/fd?u2880	3.5"  2880K Extra Density(1)
+		104 = /dev/fd?u3200	3.5"  3200K Extra Density
+		108 = /dev/fd?u3520	3.5"  3520K Extra Density
+		112 = /dev/fd?u3840	3.5"  3840K Extra Density(1)
+
+		 36 = /dev/fd?CompaQ	Compaq 2880K drive; obsolete?
+
+		(1) Autodetectable format
+		(2) Autodetectable format in a Double Density (720K) drive only
+		(3) Autodetectable format in a High Density (1440K) drive only
+
+		NOTE: The letter in the device name (d, q, h or u)
+		signifies the type of drive: 5.25" Double Density (d),
+		5.25" Quad Density (q), 5.25" High Density (h) or 3.5"
+		(any model, u).  The use of the capital letters D, H
+		and E for the 3.5" models have been deprecated, since
+		the drive type is insignificant for these devices.
+
+  3 char	Pseudo-TTY slaves
+		  0 = /dev/ttyp0	First PTY slave
+		  1 = /dev/ttyp1	Second PTY slave
+		    ...
+		256 = /dev/ttyef	256th PTY slave
+
+    block	First MFM, RLL and IDE hard disk/CD-ROM interface
+    		  0 = /dev/hda		Master: whole disk (or CD-ROM)
+		 64 = /dev/hdb		Slave: whole disk (or CD-ROM)
+		
+		For partitions, add to the whole disk device number:
+		  0 = /dev/hd?		Whole disk
+		  1 = /dev/hd?1		First partition
+		  2 = /dev/hd?2		Second partition
+		    ...
+		 63 = /dev/hd?63	63rd partition
+
+		For Linux/i386, partitions 1-4 are the primary
+		partitions, and 5 and above are logical partitions.
+		Other versions of Linux use partitioning schemes
+		appropriate to their respective architectures.
+		
+  4 char	TTY devices
+    		  0 = /dev/console	Console device
+
+		  1 = /dev/tty1		First virtual console
+		      ...
+		 63 = /dev/tty63	63rd virtual console
+		 64 = /dev/ttyS0	First serial port
+		      ...
+		127 = /dev/ttyS63	64th serial port
+		128 = /dev/ptyp0	First pseudo-tty master
+		      ...
+		191 = /dev/ptysf	64th pseudo-tty master
+		192 = /dev/ttyp0	First pseudo-tty slave
+		      ...
+		255 = /dev/ttysf	64th pseudo-tty slave
+
+		For compatibility with previous versions of Linux, the
+		first 64 PTYs are replicated under this device
+		number.  This use will be obsolescent with the release
+		of Linux 1.4 and may be removed in a future version of
+		Linux.
+
+  5 char	Alternate TTY devices
+    		  0 = /dev/tty		Current TTY device
+		 64 = /dev/cua0		Callout device corresponding to ttyS0
+		      ...
+		127 = /dev/cua63	Callout device corresponding to ttyS63
+
+  6 char	Parallel printer devices
+    		  0 = /dev/lp0		First parallel printer (0x3bc)
+		  1 = /dev/lp1		Second parallel printer (0x378)
+		  2 = /dev/lp2		Third parallel printer (0x278)
+
+		Not all computers have the 0x3bc parallel port; hence
+		the "first" printer may be either /dev/lp0 or
+		/dev/lp1.
+
+  7 char	Virtual console capture devices
+    		  0 = /dev/vcs		Current vc text contents
+		  1 = /dev/vcs1		tty1 text contents
+		      ...
+		 63 = /dev/vcs63	tty63 text contents
+		128 = /dev/vcsa		Current vc text/attribute contents
+		129 = /dev/vcsa1	tty1 text/attribute contents
+		      ...
+		191 = /dev/vcsa63	tty63 text/attribute contents
+	
+		NOTE: These devices permit both read and write access.
+
+    block	Loopback devices
+		  0 = /dev/loop0	First loopback device
+		  1 = /dev/loop1	Second loopback device
+		      ...
+
+		The loopback devices are used to mount filesystems not
+		associated with block devices.  The binding to the
+		loopback devices is usually handled by mount(8).
+
+  8 block	SCSI disk devices
+    		  0 = /dev/sda		First SCSI disk whole disk
+		 16 = /dev/sdb		Second SCSI disk whole disk
+		 32 = /dev/sdc		Third SCSI disk whole disk
+  		      ...
+		240 = /dev/sdp		Sixteenth SCSI disk whole disk
+
+		Partitions are handled in the same way as for IDE
+		disks (see major number 3) except that the limit on
+		partitions is 15.
+
+  9 char	SCSI tape devices
+    		  0 = /dev/st0		First SCSI tape, mode 0
+		  1 = /dev/st1		Second SCSI tape, mode 0
+		      ...
+    		 32 = /dev/st0l		First SCSI tape, mode 1
+		 33 = /dev/st1l		Second SCSI tape, mode 1
+		      ...
+    		 64 = /dev/st0m		First SCSI tape, mode 2
+		 65 = /dev/st1m		Second SCSI tape, mode 2
+		      ...
+    		 96 = /dev/st0a		First SCSI tape, mode 3
+		 97 = /dev/st1a		Second SCSI tape, mode 3
+		      ...
+		128 = /dev/nst0		First SCSI tape, mode 0, no rewind
+		129 = /dev/nst1		Second SCSI tape, mode 0, no rewind
+		      ...
+		160 = /dev/nst0l	First SCSI tape, mode 1, no rewind
+		161 = /dev/nst1l	Second SCSI tape, mode 1, no rewind
+		      ...
+		192 = /dev/nst0m	First SCSI tape, mode 2, no rewind
+		193 = /dev/nst1m	Second SCSI tape, mode 2, no rewind
+		      ...
+		224 = /dev/nst0a	First SCSI tape, mode 3, no rewind
+		225 = /dev/nst1a	Second SCSI tape, mode 3, no rewind
+		      ...
+
+		"No rewind" refers to the omission of the default
+		automatic rewind on device close.  The MTREW or MTOFFL
+		ioctl()'s can be used to rewind the tape regardless of
+		the device used to access it.
+
+    block	Metadisk (RAID) devices
+		  0 = /dev/md0		First metadisk group
+		  1 = /dev/md1		Second metadisk group
+		      ...
+
+		The metadisk driver is used to span a
+		filesystem across multiple physical disks.
+
+ 10 char	Non-serial mice, misc features
+		  0 = /dev/logibm	Logitech bus mouse
+		  1 = /dev/psaux	PS/2-style mouse port
+		  2 = /dev/inportbm	Microsoft Inport bus mouse
+		  3 = /dev/atibm	ATI XL bus mouse
+		  4 = /dev/jbm		J-mouse
+		  4 = /dev/amigamouse	Amiga mouse (68k/Amiga)
+		  5 = /dev/atarimouse	Atari mouse
+		  6 = /dev/sunmouse	Sun mouse
+		  7 = /dev/amigamouse1	Second Amiga mouse
+		  8 = /dev/smouse	Simple serial mouse driver
+		128 = /dev/beep		Fancy beep device
+		129 = /dev/modreq	Kernel module load request
+		130 = /dev/watchdog	Watchdog timer port
+		131 = /dev/temperature	Machine internal temperature
+		132 = /dev/hwtrap	Hardware fault trap
+		133 = /dev/exttrp	External device trap
+		134 = /dev/apm_bios	Advanced Power Management BIOS
+		135 = /dev/rtc		Real Time Clock
+		136 = /dev/qcam0	QuickCam on lp0
+		137 = /dev/qcam1	QuickCam on lp1
+		138 = /dev/qcam2	QuickCam on lp2
+		139 = /dev/openprom	SPARC OpenBoot PROM
+
+ 11 char	Raw keyboard device
+		  0 = /dev/kbd		Raw keyboard device
+
+		The raw keyboard device is used on Linux/SPARC only.
+
+    block	SCSI CD-ROM devices
+    		  0 = /dev/sr0		First SCSI CD-ROM
+		  1 = /dev/sr1		Second SCSI CD-ROM
+		      ...
+
+		The prefix /dev/scd instead of /dev/sr has been used
+		as well, and might make more sense.
+
+ 12 char	QIC-02 tape
+		  2 = /dev/ntpqic11	QIC-11, no rewind-on-close
+		  3 = /dev/tpqic11	QIC-11, rewind-on-close
+		  4 = /dev/ntpqic24	QIC-24, no rewind-on-close
+		  5 = /dev/tpqic24	QIC-24, rewind-on-close
+		  6 = /dev/ntpqic120	QIC-120, no rewind-on-close
+		  7 = /dev/tpqic120	QIC-120, rewind-on-close
+		  8 = /dev/ntpqic150	QIC-150, no rewind-on-close
+		  9 = /dev/tpqic150	QIC-150, rewind-on-close
+
+		The device names specified are proposed -- if there
+		are "standard" names for these devices, please let me know.
+
+    block	MSCDEX CD-ROM callback support
+		  0 = /dev/dos_cd0	First MSCDEX CD-ROM
+		  1 = /dev/dos_cd1	Second MSCDEX CD-ROM
+		      ...
+
+ 13 char	PC speaker
+		  0 = /dev/pcmixer	Emulates /dev/mixer
+		  1 = /dev/pcsp		Emulates /dev/dsp (8-bit)
+		  4 = /dev/pcaudio	Emulates /dev/audio
+		  5 = /dev/pcsp16	Emulates /dev/dsp (16-bit)
+    block	8-bit MFM/RLL/IDE controller
+		  0 = /dev/xda		First XT disk whole disk
+		 64 = /dev/xdb		Second XT disk whole disk
+
+		Partitions are handled in the same way as IDE disks
+		(see major number 3).
+
+ 14 char	Sound card
+		  0 = /dev/mixer	Mixer control
+		  1 = /dev/sequencer	Audio sequencer
+		  2 = /dev/midi00	First MIDI port
+		  3 = /dev/dsp		Digital audio
+		  4 = /dev/audio	Sun-compatible digital audio
+		  6 = /dev/sndstat	Sound card status information
+		  8 = /dev/sequencer2	Sequencer -- alternate device
+		 16 = /dev/mixer1	Second soundcard mixer control
+		 17 = /dev/patmgr0	Sequencer patch manager
+		 18 = /dev/midi01	Second MIDI port
+		 19 = /dev/dsp1		Second soundcard digital audio
+		 20 = /dev/audio1	Second soundcard Sun digital audio
+		 33 = /dev/patmgr1	Sequencer patch manager
+		 34 = /dev/midi02	Third MIDI port
+		 50 = /dev/midi03	Fourth MIDI port
+    block	BIOS harddrive callback support
+		  0 = /dev/dos_hda	First BIOS harddrive whole disk
+		 64 = /dev/dos_hdb	Second BIOS harddrive whole disk
+		128 = /dev/dos_hdc	Third BIOS harddrive whole disk
+		192 = /dev/dos_hdd	Fourth BIOS harddrive whole disk
+
+		Partitions are handled in the same way as IDE disks
+		(see major number 3).
+
+ 15 char	Joystick
+		  0 = /dev/js0		First analog joystick
+		  1 = /dev/js1		Second analog joystick
+		    ...
+		128 = /dev/djs0		First digital joystick
+		129 = /dev/djs1		Second digital joystick
+		    ...
+    block	Sony CDU-31A/CDU-33A CD-ROM
+		  0 = /dev/sonycd	Sony CDU-31a CD-ROM
+
+ 16 char	Non-SCSI scanners
+		  0 = /dev/gs4500	Genius 4500 handheld scanner
+    block	GoldStar CD-ROM
+		  0 = /dev/gscd		GoldStar CD-ROM
+
+ 17 char	Chase serial card
+		  0 = /dev/ttyH0	First Chase port
+		  1 = /dev/ttyH1	Second Chase port
+		      ...
+    block	Optics Storage CD-ROM
+		  0 = /dev/optcd	Optics Storage CD-ROM
+
+ 18 char	Chase serial card - alternate devices
+		  0 = /dev/cuh0		Callout device corresponding to ttyH0
+		  1 = /dev/cuh1		Callout device corresponding to ttyH1
+		      ...
+    block	Sanyo CD-ROM
+		  0 = /dev/sjcd		Sanyo CD-ROM
+
+ 19 char	Cyclades serial card
+		  0 = /dev/ttyC0	First Cyclades port
+		      ...
+		 31 = /dev/ttyC31	32nd Cyclades port
+    block	"Double" compressed disk
+		  0 = /dev/double0	First compressed disk
+		      ...
+		  7 = /dev/double7	Eighth compressed disk
+		128 = /dev/cdouble0	Mirror of first compressed disk
+		      ...
+		135 = /dev/cdouble7	Mirror of eighth compressed disk
+
+		See the Double documentation for the meaning of the
+		mirror devices.
+
+ 20 char	Cyclades serial card - alternate devices
+		  0 = /dev/cub0		Callout device corresponding to ttyC0
+		      ...
+		 31 = /dev/cub31	Callout device corresponding to ttyC31
+    block	Hitachi CD-ROM (under development)
+		  0 = /dev/hitcd	Hitachi CD-ROM
+
+ 21 char	Generic SCSI access
+		  0 = /dev/sg0		First generic SCSI device
+		  1 = /dev/sg1		Second generic SCSI device
+		      ...
+
+ 22 char	Digiboard serial card
+		  0 = /dev/ttyD0	First Digiboard port
+		  1 = /dev/ttyD1	Second Digiboard port
+		      ...
+    block	Second IDE hard disk/CD-ROM interface
+    		  0 = /dev/hdc		Master: whole disk (or CD-ROM)
+		 64 = /dev/hdd		Slave: whole disk (or CD-ROM)
+		
+		Partitions are handled the same way as for the first
+		interface (see major number 3).
+
+ 23 char	Digiboard serial card - alternate devices
+		  0 = /dev/cud0		Callout device corresponding to ttyD0
+		  1 = /dev/cud1		Callout device corresponding to ttyD1
+		      ...
+    block	Mitsumi proprietary CD-ROM
+		  0 = /dev/mcd		Mitsumi CD-ROM
+
+ 24 char	Stallion serial card
+		  0 = /dev/ttyE0	Stallion port 0 card 0
+		  1 = /dev/ttyE1	Stallion port 1 card 0
+		      ...
+		 64 = /dev/ttyE64	Stallion port 0 card 1
+		 65 = /dev/ttyE65	Stallion port 1 card 1
+		      ...
+		128 = /dev/ttyE128	Stallion port 0 card 2
+		129 = /dev/ttyE129	Stallion port 1 card 2
+		      ...
+		192 = /dev/ttyE192	Stallion port 0 card 3
+		193 = /dev/ttyE193	Stallion port 1 card 3
+		      ...
+    block	Sony CDU-535 CD-ROM
+		  0 = /dev/cdu535	Sony CDU-535 CD-ROM
+
+ 25 char	Stallion serial card - alternate devices
+		  0 = /dev/cue0		Callout device corresponding to ttyE0
+		  1 = /dev/cue1		Callout device corresponding to ttyE1
+		      ...
+		 64 = /dev/cue64	Callout device corresponding to ttyE64
+		 65 = /dev/cue65	Callout device corresponding to ttyE65
+		      ...
+		128 = /dev/cue128	Callout device corresponding to ttyE128
+		129 = /dev/cue129	Callout device corresponding to ttyE129
+		      ...
+		192 = /dev/cue192	Callout device corresponding to ttyE192
+		193 = /dev/cue193	Callout device corresponding to ttyE193
+		      ...
+    block	First Matsushita (Panasonic/SoundBlaster) CD-ROM
+		  0 = /dev/sbpcd0	Panasonic CD-ROM controller 0 unit 0
+		  1 = /dev/sbpcd1	Panasonic CD-ROM controller 0 unit 1
+		  2 = /dev/sbpcd2	Panasonic CD-ROM controller 0 unit 2
+		  3 = /dev/sbpcd3	Panasonic CD-ROM controller 0 unit 3
+
+ 26 char	Quanta WinVision frame grabber
+		  0 = /dev/wvisfgrab	Quanta WinVision frame grabber
+    block	Second Matsushita (Panasonic/SoundBlaster) CD-ROM
+		  0 = /dev/sbpcd4	Panasonic CD-ROM controller 1 unit 0
+		  1 = /dev/sbpcd5	Panasonic CD-ROM controller 1 unit 1
+		  2 = /dev/sbpcd6	Panasonic CD-ROM controller 1 unit 2
+		  3 = /dev/sbpcd7	Panasonic CD-ROM controller 1 unit 3
+
+ 27 char	QIC-117 tape
+		  0 = /dev/rft0		Unit 0, rewind-on-close
+		  1 = /dev/rft1		Unit 1, rewind-on-close
+		  2 = /dev/rft2		Unit 2, rewind-on-close
+		  3 = /dev/rft3		Unit 3, rewind-on-close
+		  4 = /dev/nrft0	Unit 0, no rewind-on-close
+		  5 = /dev/nrft1	Unit 1, no rewind-on-close
+		  6 = /dev/nrft2	Unit 2, no rewind-on-close
+		  7 = /dev/nrft3	Unit 3, no rewind-on-close
+    block	Third Matsushita (Panasonic/SoundBlaster) CD-ROM
+		  0 = /dev/sbpcd8	Panasonic CD-ROM controller 2 unit 0
+		  1 = /dev/sbpcd9	Panasonic CD-ROM controller 2 unit 1
+		  2 = /dev/sbpcd10	Panasonic CD-ROM controller 2 unit 2
+		  3 = /dev/sbpcd11	Panasonic CD-ROM controller 2 unit 3
+
+ 28 char	Stallion serial card - card programming
+		  0 = /dev/staliomem0	First Stallion card I/O memory
+		  1 = /dev/staliomem1	Second Stallion card I/O memory
+		  2 = /dev/staliomem2	Third Stallion card I/O memory
+		  3 = /dev/staliomem3	Fourth Stallion card I/O memory
+    char	Atari SLM ACSI laser printer (68k/Atari)
+		  0 = /dev/slm0		First SLM laser printer
+		  1 = /dev/slm1		Second SLM laser printer
+		      ...
+    block	Fourth Matsushita (Panasonic/SoundBlaster) CD-ROM
+		  0 = /dev/sbpcd12	Panasonic CD-ROM controller 3 unit 0
+		  1 = /dev/sbpcd13	Panasonic CD-ROM controller 3 unit 1
+		  2 = /dev/sbpcd14	Panasonic CD-ROM controller 3 unit 2
+		  3 = /dev/sbpcd15	Panasonic CD-ROM controller 3 unit 3
+    block	ACSI disk (68k/Atari)
+		  0 = /dev/ada		First ACSI disk whole disk
+		 16 = /dev/adb		Second ACSI disk whole disk
+		 32 = /dev/adc		Third ACSI disk whole disk
+		      ...
+		240 = /dev/adp		16th ACSI disk whole disk
+
+		Partitions are handled in the same way as for IDE
+		disks (see major number 3) except that the limit on
+		partitions is 15, like SCSI.
+
+ 29 char	Universal frame buffer
+		  0 = /dev/fb0		First frame buffer
+		  1 = /dev/fb0autodetect
+		 24 = /dev/fb0user0
+	              ...
+		 31 = /dev/fb0user7
+		 32 = /dev/fb1		Second frame buffer
+		 33 = /dev/fb1autodetect
+		 56 = /dev/fb1user0
+		      ...
+		 63 = /dev/fb1user7
+
+		The universal frame buffer device is currently only
+		supported on Linux/68k and Linux/SPARC.  The plain
+		device accesses the frame buffer at current resolution
+		(Linux/68k calls this device "current",
+		e.g. /dev/fb0current); the "autodetect" one at bootup
+		(default) resolution.  Minor numbers 2-23 within each
+		frame buffer assignment are used for specific
+		device-dependent resolutions.  There appears to be no
+		standard naming for these devices.  Finally, 2-31
+		within each device are reserved for user-selected
+		modes, usually entered at boot time.  Currently only
+		Linux/68k uses the mode-specific devices.
+
+    block	Aztech/Orchid/Okano/Wearnes CD-ROM
+		  0 = /dev/aztcd	Aztech CD-ROM
+
+ 30 char	iBCS-2 compatibility devices
+		  0 = /dev/socksys	Socket access
+		  1 = /dev/spx		SVR3 local X interface
+		  2 = /dev/inet/arp	Network access
+		  2 = /dev/inet/icmp	Network access
+		  2 = /dev/inet/ip	Network access
+		  2 = /dev/inet/udp	Network access
+		  2 = /dev/inet/tcp	Network access
+
+		iBCS-2 requires /dev/nfsd to be a link to
+		/dev/socksys, and /dev/X0R to be a link to /dev/null.
+
+    block	Philips LMS CM-205 CD-ROM
+		  0 = /dev/cm205cd	Philips LMS CM-205 CD-ROM
+
+		/dev/lmscd is an older name for this device.  This
+		driver does not work with the CM-205MS CD-ROM.
+
+ 31 char	MPU-401 MIDI
+		  0 = /dev/mpu401data	MPU-401 data port
+		  1 = /dev/mpu401stat	MPU-401 status port
+    block	ROM/flash memory card
+		  0 = /dev/rom0		First ROM card (rw)
+		      ...
+		  7 = /dev/rom7		Eighth ROM card (rw)
+		  8 = /dev/rrom0	First ROM card (ro)
+		      ...
+		 15 = /dev/rrom7	Eighth ROM card (ro)
+		 16 = /dev/flash0	First flash memory card (rw)
+		      ...
+		 23 = /dev/flash7	Eighth flash memory card (rw)
+		 24 = /dev/rflash0	First flash memory card (ro)
+		      ...
+		 31 = /dev/rflash7	Eighth flash memory card (ro)
+
+		The read-write (rw) devices support back-caching
+		written data in RAM, as well as writing to flash RAM
+		devices.  The read-only devices (ro) support reading
+		only.
+
+ 32 char	Specialix serial card
+		  0 = /dev/ttyX0	First Specialix port
+		  1 = /dev/ttyX1	Second Specialix port
+		      ...
+    block	Philips LMS CM-206 CD-ROM
+		  0 = /dev/cm206cd	Philips LMS CM-206 CD-ROM
+
+ 33 char	Specialix serial card - alternate devices
+		  0 = /dev/cux0		Callout device corresponding to ttyX0
+		  1 = /dev/cux1		Callout device corresponding to ttyX1
+		      ...
+    block	Third IDE hard disk/CD-ROM interface
+    		  0 = /dev/hde		Master: whole disk (or CD-ROM)
+		 64 = /dev/hdf		Slave: whole disk (or CD-ROM)
+
+		Partitions are handled the same way as for the first
+		interface (see major number 3).
+
+ 34 char	Z8530 HDLC driver
+		  0 = /dev/scc0		First Z8530, first port
+		  1 = /dev/scc1		First Z8530, second port
+		  2 = /dev/scc2		Second Z8530, first port
+		  3 = /dev/scc3		Second Z8530, second port
+		      ...
+
+		In a previous version these devices were named
+		/dev/sc1 for /dev/scc0, /dev/sc2 for /dev/scc1, and so
+		on.
+
+    block	Fourth IDE hard disk/CD-ROM interface
+    		  0 = /dev/hdg		Master: whole disk (or CD-ROM)
+		 64 = /dev/hdh		Slave: whole disk (or CD-ROM)
+		
+		Partitions are handled the same way as for the first
+		interface (see major number 3).
+
+ 35 char	tclmidi MIDI driver
+		  0 = /dev/midi0	First MIDI port, kernel timed
+		  1 = /dev/midi1	Second MIDI port, kernel timed
+		  2 = /dev/midi2	Third MIDI port, kernel timed
+		  3 = /dev/midi3	Fourth MIDI port, kernel timed
+	         64 = /dev/rmidi0	First MIDI port, untimed
+	         65 = /dev/rmidi1	Second MIDI port, untimed
+	         66 = /dev/rmidi2	Third MIDI port, untimed
+	         67 = /dev/rmidi3	Fourth MIDI port, untimed
+		128 = /dev/smpte0	First MIDI port, SMPTE timed
+		129 = /dev/smpte1	Second MIDI port, SMPTE timed
+		130 = /dev/smpte2	Third MIDI port, SMPTE timed
+		131 = /dev/smpte3	Fourth MIDI port, SMPTE timed
+    block	Modular RAM disk device
+
+		This device number is provided for older kernels which
+		did not have the modular RAM disk in the standard
+		distribution.  See major number 1.  This assignment
+		will be removed when the 2.0 kernel is released.
+
+ 36 char	Netlink support
+		  0 = /dev/route	Routing, device updates, kernel to user
+		  1 = /dev/skip		enSKIP security cache control
+    block	MCA ESDI hard disk
+		  0 = /dev/eda		First ESDI disk whole disk
+		 64 = /dev/edb		Second ESDI disk whole disk
+		      ...
+
+		Partitions are handled in the same way as IDE disks
+		(see major number 3).
+
+ 37 char	IDE tape
+		  0 = /dev/ht0		First IDE tape
+		128 = /dev/nht0		First IDE tape, no rewind-on-close
+
+		Currently, only one IDE tape drive is supported.
+
+    block	Zorro II ramdisk
+		  0 = /dev/z2ram	Zorro II ramdisk
+
+ 38 char	Myricom PCI Myrinet board
+		  0 = /dev/mlanai0	First Myrinet board
+		  1 = /dev/mlanai1	Second Myrinet board
+		      ...
+
+		This device is used for status query, board control
+		and "user level packet I/O."  This board is also
+		accessible as a standard networking "eth" device.
+
+    block	Reserved for Linux/AP+
+
+ 39 char	ML-16P experimental I/O board
+		  0 = /dev/ml16pa-a0	First card, first analog channel
+		  1 = /dev/ml16pa-a1	First card, second analog channel
+		      ...
+		 15 = /dev/ml16pa-a15	First card, 16th analog channel
+		 16 = /dev/ml16pa-d	First card, digital lines
+		 17 = /dev/ml16pa-c0	First card, first counter/timer
+		 18 = /dev/ml16pa-c1	First card, second counter/timer
+		 19 = /dev/ml16pa-c2	First card, third counter/timer
+		 32 = /dev/ml16pb-a0	Second card, first analog channel
+		 33 = /dev/ml16pb-a1	Second card, second analog channel
+		      ...
+		 47 = /dev/ml16pb-a15	Second card, 16th analog channel
+		 48 = /dev/ml16pb-d	Second card, digital lines
+		 49 = /dev/ml16pb-c0	Second card, first counter/timer
+		 50 = /dev/ml16pb-c1	Second card, second counter/timer
+		 51 = /dev/ml16pb-c2	Second card, third counter/timer
+		      ...
+    block	Reserved for Linux/AP+
+
+ 40 char	Matrox Meteor frame grabber
+		  0 = /dev/mmetfgrab	Matrox Meteor frame grabber
+    block	Syquest EZ135 parallel port removable drive
+		  0 = /dev/eza		Parallel EZ135 drive, whole disk
+
+		Partitions are handled in the same way as IDE disks
+		(see major number 3).
+
+ 41 char	Yet Another Micro Monitor
+		  0 = /dev/yamm		Yet Another Micro Monitor
+    block	MicroSolutions BackPack parallel port CD-ROM
+		  0 = /dev/bpcd		BackPack CD-ROM
+
+ 42		Demo/sample use
+
+		This number is intended for use in sample code, as
+		well as a general "example" device number.  It
+		should never be used for a device driver that is being
+		distributed; either obtain an official number or use
+		the local/experimental range.  The sudden addition or
+		removal of a driver with this number should not cause
+		ill effects to the system (bugs excepted.)
+
+ 43 char	isdn4linux virtual modem
+		  0 = /dev/ttyI0	First virtual modem
+		      ...
+		 63 = /dev/ttyI63	64th virtual modem
+
+ 44 char	isdn4linux virtual modem - alternate devices
+		  0 = /dev/cui0		Callout device corresponding to ttyI0
+		      ...
+		 63 = /dev/cui63	Callout device corresponding to ttyI63
+
+ 45 char	isdn4linux ISDN BRI driver
+		  0 = /dev/isdn0	First virtual B channel raw data
+		      ...
+		 63 = /dev/isdn63	64th virtual B channel raw data
+		 64 = /dev/isdnctrl0	First channel control/debug
+		      ...
+		127 = /dev/isdnctrl63	64th channel control/debug
+
+		128 = /dev/ippp0	First SyncPPP device
+		      ...
+		191 = /dev/ippp63	64th SyncPPP device
+
+		255 = /dev/isdninfo	ISDN monitor interface
+
+ 46 char	Comtrol Rocketport serial card
+		  0 = /dev/ttyR0	First Rocketport port
+		  1 = /dev/ttyR1	Second Rocketport port
+		      ...
+
+ 47 char	Comtrol Rocketport serial card - alternate devices
+		  0 = /dev/cur0		Callout device corresponding to ttyR0
+		  1 = /dev/cur1		Callout device corresponding to ttyR1
+		      ...
+
+ 48 char	SDL RISCom serial card
+		  0 = /dev/ttyL0	First RISCom port
+		  1 = /dev/ttyL1	Second RISCom port
+		      ...
+
+ 49 char	SDL RISCom serial card - alternate devices
+		  0 = /dev/cul0		Callout device corresponding to ttyL0
+		  1 = /dev/cul1		Callout device corresponding to ttyL1
+		      ...
+
+ 50 char	Reserved for GLINT
+
+ 51 char	Baycom radio modem
+		  0 = /dev/bc0		First Baycom radio modem
+		  1 = /dev/bc1		Second Baycom radio modem
+		      ...
+
+ 52 char	Spellcaster DataComm/BRI ISDN card
+		  0 = /dev/dcbri0	First DataComm card
+		  1 = /dev/dcbri1	Second DataComm card
+		  2 = /dev/dcbri2	Third DataComm card
+		  3 = /dev/dcbri3	Fourth DataComm card
+
+ 53 char	BDM interface for remote debugging MC683xx microcontrollers
+		  0 = /dev/pd_bdm0	PD BDM interface on lp0
+          	  1 = /dev/pd_bdm1	PD BDM interface on lp1
+          	  2 = /dev/pd_bdm2	PD BDM interface on lp2
+		  4 = /dev/icd_bdm0	ICD BDM interface on lp0
+		  5 = /dev/icd_bdm1	ICD BDM interface on lp1
+		  6 = /dev/icd_bdm2	ICD BDM interface on lp2
+
+		This device is used for the interfacing to the MC683xx
+		microcontrollers via Background Debug Mode by use of a
+		Parallel Port interface. PD is the Motorola Public
+		Domain Interface and ICD is the commercial interface
+		by P&E.
+
+ 54 char	Electrocardiognosis Holter serial card
+		  0 = /dev/holter0	First Holter port
+		  1 = /dev/holter1	Second Holter port
+		  2 = /dev/holter2	Third Holter port
+
+		A custom serial card used by Electrocardiognosis SRL
+		<mseritan@ottonel.pub.ro> to transfer data from Holter
+		24-hour heart monitoring equipment.
+
+ 55 char	DSP56001 digital signal processor
+		  0 = /dev/dsp56k	First DSP56001
+
+ 56 char	Apple Desktop Bus
+		  0 = /dev/adb		ADB bus control
+
+		Additional devices will be added to this number, all
+		starting with /dev/adb.
+
+ 57 char	Hayes ESP serial card
+		  0 = /dev/ttyP0	First ESP port
+		  1 = /dev/ttyP1	Second ESP port
+		      ...
+
+ 58 char	Hayes ESP serial card - alternate devices
+		  0 = /dev/cup0		Callout device corresponding to ttyP0
+		  1 = /dev/cup1		Callout device corresponding to ttyP1
+		      ...
+
+ 59 char	sf firewall package
+		  0 = /dev/firewall	Communication with sf kernel module
+
+ 60-63		LOCAL/EXPERIMENTAL USE
+		Allocated for local/experimental use.  For devices not
+		assigned official numbers, these ranges should be
+		used, in order to avoid conflicting with future assignments.
+
+ 64-119		UNALLOCATED
+
+120-127		LOCAL/EXPERIMENTAL USE
+
+128-239		UNALLOCATED
+
+240-254		LOCAL/EXPERIMENTAL USE
+
+255		RESERVED
+
+
+
+
+	ADDITIONAL /dev DIRECTORY ENTRIES
+
+This section details additional entries that should or may exist in
+the /dev directory.  It is preferred that symbolic links use the same
+form (absolute or relative) as is indicated here.  Links are
+classified as "hard" or "symbolic" depending on the preferred type of
+link; if possible, the indicated type of link should be used.
+
+
+	Compulsory links
+
+These links should exist on all systems:
+
+/dev/fd		/proc/self/fd	symbolic	File descriptors
+/dev/stdin	fd/0		symbolic	stdin file descriptor
+/dev/stdout	fd/1		symbolic	stdout file descriptor
+/dev/stderr	fd/2		symbolic	stderr file descriptor
+/dev/nfsd	socksys		symbolic	Required by iBCS-2
+/dev/X0R	null		symbolic	Required by iBCS-2
+
+Note: the last device is <letter X>-<digit 0>-<letter R>.
+
+	Recommended links
+
+It is recommended that these links exist on all systems:
+
+/dev/core	/proc/kcore	symbolic	Backward compatibility
+/dev/ramdisk	ram0		symbolic	Backward compatibility
+/dev/ftape	rft0		symbolic	Backward compatibility
+/dev/scd?	sr?		hard		Alternate SCSI CD-ROM name
+
+
+	Locally defined links
+
+The following links may be established locally to conform to the
+configuration of the system.  This is merely a tabulation of existing
+practice, and does not constitute a recommendation.  However, if they
+exist, they should have the following uses.
+
+/dev/mouse	mouse port	symbolic	Current mouse device
+/dev/tape	tape device	symbolic	Current tape device
+/dev/cdrom	CD-ROM device	symbolic	Current CD-ROM device
+/dev/cdwriter	CD-writer	symbolic	Current CD-writer device
+/dev/scanner	scanner		symbolic	Current scanner device
+/dev/modem	modem port	symbolic	Current dialout device
+/dev/root	root device	symbolic	Current root filesystem
+/dev/swap	swap device	symbolic	Current swap device
+
+/dev/modem should not be used for a modem which supports dialin as
+well as dialout, as it tends to cause lock file problems.  If it
+exists, /dev/modem should point to the appropriate dialout (alternate)
+device.
+
+For SCSI devices, /dev/tape and /dev/cdrom should point to the
+``cooked'' devices (/dev/st* and /dev/sr*, respectively), whereas
+/dev/cdwriter and /dev/scanner should point to the appropriate generic
+SCSI devices (/dev/sg*).
+
+/dev/mouse may point to a primary serial TTY device, a hardware mouse
+device, or a socket for a mouse driver program (e.g. /dev/gpmdata).
+
+	Sockets and pipes
+
+Non-transient sockets and named pipes may exist in /dev.  Common entries are:
+
+/dev/printer	socket		lpd local socket
+/dev/log	socket		syslog local socket
+/dev/gpmdata	socket		gpm mouse multiplexer
diff --git a/Documentation/digiboard.txt b/Documentation/digiboard.txt
new file mode 100644
index 000000000..654d87d4b
--- /dev/null
+++ b/Documentation/digiboard.txt
@@ -0,0 +1,155 @@
+The Linux Digiboard Driver
+--------------------------
+
+The Digiboard Driver for Linux supports the following boards:
+
+ DigiBoard PC/Xe, PC/Xi, PC/Xeve
+
+Limitations:
+------------
+Currently the Driver does not do autoprobing!
+
+The preconfigured I/O address is 0200h and the default memory address
+0D0000h, ALT-PIN feature on and 16 ports available.
+
+Use them and you will not have to worry about configuring anything.
+
+You can configure the driver via lilo. Have a look at the end of this
+message. The default settings vanish as soon as you give a digi= commandline.
+You can give multiple digi= commandline parameters to define multiple
+boards.
+
+Supporting Tools:
+-----------------
+Some tools and more detailed information can be found at
+ftp://ftp.fuller.edu/Linux/digi
+
+WARNING: Most of the stuff available right now uses the WRONG Major Device
+numbers and the wrong call out devices. Be careful and check them first.
+Better not use any of the software in that directory if you run a recent
+1.3.X Kernel or later!
+
+The "ditty" tool described in the Digiboard Manuals for other Unixes
+is also available.
+
+Currently the Linux MAKEDEV command does not support generating the Digiboard
+Devices. Use the following script to generate the devices:
+
+------------------ mkdigidev begin
+#!/bin/sh
+#
+# Script to create Digiboard Devices
+# Christoph Lameter, April 16, 1996
+#
+# Usage:
+# mkdigidev [<number of devices>]
+# 
+
+DIGI_MAJOR=23
+DIGICU_MAJOR=22
+
+BOARDS=$1
+
+if [ "$BOARDS" = "" ]; then
+BOARDS=1
+fi
+
+boardnum=0
+while [ $boardnum -lt $BOARDS ];
+do
+  for c in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15;
+  do
+	name=`expr $boardnum \* 16 + $c`
+	mknod /dev/cud$name c $DIGICU_MAJOR $name
+	mknod /dev/ttyD$name c $DIGI_MAJOR $name
+  done
+  boardnum=`expr $boardnum + 1`
+done
+------------------ mkdigidev end
+or apply the following patch to /dev/MAKEDEV and do a 
+make digi
+----- MAKEDEV Patch
+--- /dev/MAKEDEV	Sun Aug 13 15:48:23 1995
++++ MAKEDEV	Tue Apr 16 17:53:27 1996
+@@ -120,7 +120,7 @@
+ 	while [ $# -ne 0 ]
+ 	do
+ 		case "$1" in
+-			mem|tty|ttyp|cua|cub)	;;
++			mem|tty|ttyp|cua|cub|cud)	;;
+ 			hd)	echo hda hdb hdc hdd ;;
+ 			xd)	echo xda xdb ;;
+ 			fd)	echo fd0 fd1 ;;
+@@ -140,6 +140,7 @@
+ 			dcf)		echo dcf ;;
+ 			pcmcia)	;; # taken care of by its own driver
+ 			ttyC)	echo cyclades ;;
++			ttyD)	echo digi ;;
+ 			*)	echo "$0: don't know what \"$1\" is" >&2 ;;
+ 		esac
+ 		shift
+@@ -208,6 +209,15 @@
+ 		do
+ 			makedev ttyC$i c $major1 `expr 32 + $i` $tty
+ 			makedev cub$i c $major2 `expr 32 + $i` $dialout
++		done
++		;;
++	digi)
++		major1=`Major ttyD` || continue
++		major2=`Major cud` || continue
++		for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
++		do
++			makedev ttyD$i c $major1 `expr 32 + $i` $tty
++			makedev cud$i c $major2 `expr 32 + $i` $dialout
+ 		done
+ 		;;
+ 	par[0-2])
+----- End Makedev patch
+
+The /dev/cud?? devices behave like the /dev/cua?? devices
+and the ttyD devices are like the /dev/ttyS?? devices.
+
+Sources of Information
+----------------------
+
+Webpage: http://private.fuller.edu/clameter/digi.html
+
+Mailing List: digiboard@list.fuller.edu
+
+(Write e-mail to that address to subscribe. Common ListServ commands work.
+Archive of messages available)
+
+Christoph Lameter (clameter@fuller.edu) 16. April 1996.
+
+-----------------------------------------------------------------------------
+
+Changes v1.5.5:
+
+The ability to use the kernel's command line to pass in the configuration for 
+boards.  Using LILO's APPEND command, a string of comma separated identifiers 
+or integers can be used.  The 6 values in order are:
+
+   Enable/Disable this card,
+   Type of card: PC/Xi(0), PC/Xe(1), PC/Xeve(2), PC/Xem(3)
+   Enable/Disable alternate pin arrangement,
+   Number of ports on this card,
+   I/O Port where card is configured (in HEX if using string identifiers),
+   Base of memory window (in HEX if using string identifiers), 
+
+Samples:
+   append="digi=E,PC/Xi,D,16,200,D0000"
+   append="digi=1,0,0,16,512,(whatever D0000 is in base 10 :)
+
+Driver's minor device numbers are conserved. This means that instead of
+each board getting a block of 16 minors pre-assigned, it gets however
+many it should, with the next card following directly behind it.  A
+system with 4 2-port PC/Xi boards will use minor numbers 0-7.
+This conserves some memory, and removes a few hard coded constants.
+
+NOTE!! NOTE!! NOTE!!
+The definition of PC/Xem as a valid board type is the BEGINNING of support
+for this device.  The driver does not currently recognise the board, nor
+does it want to initialize it.  At least not the EISA version.
+
+Mike McLagan <mike.mclagan@linux.org> 5, April 1996.
+
diff --git a/Documentation/exception.txt b/Documentation/exception.txt
new file mode 100644
index 000000000..78118f1d5
--- /dev/null
+++ b/Documentation/exception.txt
@@ -0,0 +1,286 @@
+     Kernel level exception handling in Linux 2.1.8
+  Commentary by Joerg Pommnitz <joerg@raleigh.ibm.com>
+
+When a process runs in kernel mode, it often has to access user 
+mode memory whose address has been passed by an untrusted program. 
+To protect itself the kernel has to verify this address.
+
+In older versions of Linux this was done with the 
+int verify_area(int type, const void * addr, unsigned long size) 
+function.
+
+This function verified, that the memory area starting at address 
+addr and of size size was accessible for the operation specified 
+in type (read or write). To do this, verify_read had to look up the 
+virtual memory area (vma) that contained the address addr. In the 
+normal case (correctly working program), this test was successful. 
+It only failed for the (hopefully) rare, buggy program. In some kernel 
+profiling tests, this normally unneeded verification used up a 
+considerable amount of time.
+
+To overcome this situation, Linus decided to let the virtual memory 
+hardware present in every Linux capable CPU handle this test.
+
+How does this work?
+
+Whenever the kernel tries to access an address that is currently not 
+accessible, the CPU generates a page fault exception and calls the 
+page fault handler 
+
+void do_page_fault(struct pt_regs *regs, unsigned long error_code)
+
+in arch/i386/mm/fault.c. The parameters on the stack are set up by 
+the low level assembly glue in arch/i386/kernel/entry.S. The parameter
+regs is a pointer to the saved registers on the stack, error_code 
+contains a reason code for the exception.
+
+do_page_fault first obtains the unaccessible address from the CPU 
+control register CR2. If the address is within the virtual address 
+space of the process, the fault probably occured, because the page 
+was not swapped in, write protected or something similiar. However, 
+we are interested in the other case: the address is not valid, there 
+is no vma that contains this address. In this case, the kernel jumps 
+to the bad_area label. 
+
+There it uses the address of the instruction that caused the exception 
+(i.e. regs->eip) to find an address where the excecution can continue 
+(fixup). If this search is successful, the fault handler modifies the 
+return address (again regs->eip) and returns. The execution will 
+continue at the address in fixup.
+
+Where does fixup point to?
+
+Since we jump to the the contents of fixup, fixup obviously points 
+to executable code. This code is hidden inside the user access macros. 
+I have picked the get_user macro defined in include/asm/uacess.h as an
+example. The definition is somewhat hard to follow, so lets peek at 
+the code generated by the preprocessor and the compiler. I selected
+the get_user call in drivers/char/console.c for a detailed examination.
+
+The original code in console.c line 1405:
+        get_user(c, buf);
+
+The preprocessor output (edited to become somewhat readable):
+
+(
+  {        
+    long __gu_err = - 14 , __gu_val = 0;        
+    const __typeof__(*( (  buf ) )) *__gu_addr = ((buf));        
+    if (((((0 + current_set[0])->tss.segment) == 0x18 )  || 
+       (((sizeof(*(buf))) <= 0xC0000000UL) && 
+       ((unsigned long)(__gu_addr ) <= 0xC0000000UL - (sizeof(*(buf)))))))        
+      do {
+        __gu_err  = 0;        
+        switch ((sizeof(*(buf)))) {        
+          case 1: 
+            __asm__ __volatile__(        
+              "1:      mov" "b" " %2,%" "b" "1\n"        
+              "2:\n"        
+              ".section .fixup,\"ax\"\n"        
+              "3:      movl %3,%0\n"        
+              "        xor" "b" " %" "b" "1,%" "b" "1\n"        
+              "        jmp 2b\n"        
+              ".section __ex_table,\"a\"\n"        
+              "        .align 4\n"        
+              "        .long 1b,3b\n"        
+              ".text"        : "=r"(__gu_err), "=q" (__gu_val): "m"((*(struct __large_struct *)
+                            (   __gu_addr   )) ), "i"(- 14 ), "0"(  __gu_err  )) ; 
+              break;        
+          case 2: 
+            __asm__ __volatile__(
+              "1:      mov" "w" " %2,%" "w" "1\n"        
+              "2:\n"        
+              ".section .fixup,\"ax\"\n"        
+              "3:      movl %3,%0\n"        
+              "        xor" "w" " %" "w" "1,%" "w" "1\n"        
+              "        jmp 2b\n"        
+              ".section __ex_table,\"a\"\n"        
+              "        .align 4\n"        
+              "        .long 1b,3b\n"        
+              ".text"        : "=r"(__gu_err), "=r" (__gu_val) : "m"((*(struct __large_struct *)
+                            (   __gu_addr   )) ), "i"(- 14 ), "0"(  __gu_err  )); 
+              break;        
+          case 4: 
+            __asm__ __volatile__(        
+              "1:      mov" "l" " %2,%" "" "1\n"        
+              "2:\n"        
+              ".section .fixup,\"ax\"\n"        
+              "3:      movl %3,%0\n"        
+              "        xor" "l" " %" "" "1,%" "" "1\n"        
+              "        jmp 2b\n"        
+              ".section __ex_table,\"a\"\n"        
+              "        .align 4\n"        "        .long 1b,3b\n"        
+              ".text"        : "=r"(__gu_err), "=r" (__gu_val) : "m"((*(struct __large_struct *)
+                            (   __gu_addr   )) ), "i"(- 14 ), "0"(__gu_err)); 
+              break;        
+          default: 
+            (__gu_val) = __get_user_bad();        
+        }        
+      } while (0) ;        
+    ((c)) = (__typeof__(*((buf))))__gu_val;        
+    __gu_err;
+  }
+);
+
+WOW! Black GCC/assembly magic. This is impossible to follow, so lets
+see what code gcc generates:
+
+ >         xorl %edx,%edx
+ >         movl current_set,%eax
+ >         cmpl $24,788(%eax)        
+ >         je .L1424        
+ >         cmpl $-1073741825,64(%esp)
+ >         ja .L1423                
+ > .L1424:
+ >         movl %edx,%eax                        
+ >         movl 64(%esp),%ebx
+ > #APP
+ > 1:      movb (%ebx),%dl                /* this is the actual user access */
+ > 2:
+ > .section .fixup,"ax"
+ > 3:      movl $-14,%eax
+ >         xorb %dl,%dl
+ >         jmp 2b
+ > .section __ex_table,"a"
+ >         .align 4
+ >         .long 1b,3b
+ > .text
+ > #NO_APP
+ > .L1423:
+ >         movzbl %dl,%esi
+
+The optimizer does a good job and gives us something we can actually 
+understand. Can we? The actual user access is quite obvious. Thanks 
+to the unified address space we can just access the address in user 
+memory. But what does the .section stuff do?????
+
+To understand this we have to look at the final kernel:
+
+ > objdump --section-headers vmlinux
+ > 
+ > vmlinux:     file format elf32-i386
+ > 
+ > Sections:
+ > Idx Name          Size      VMA       LMA       File off  Algn
+ >   0 .text         00098f40  c0100000  c0100000  00001000  2**4
+ >                   CONTENTS, ALLOC, LOAD, READONLY, CODE
+ >   1 .fixup        000016bc  c0198f40  c0198f40  00099f40  2**0
+ >                   CONTENTS, ALLOC, LOAD, READONLY, CODE
+ >   2 .rodata       0000f127  c019a5fc  c019a5fc  0009b5fc  2**2
+ >                   CONTENTS, ALLOC, LOAD, READONLY, DATA
+ >   3 __ex_table    000015c0  c01a9724  c01a9724  000aa724  2**2
+ >                   CONTENTS, ALLOC, LOAD, READONLY, DATA
+ >   4 .data         0000ea58  c01abcf0  c01abcf0  000abcf0  2**4
+ >                   CONTENTS, ALLOC, LOAD, DATA
+ >   5 .bss          00018e21  c01ba748  c01ba748  000ba748  2**2
+ >                   ALLOC
+ >   6 .comment      00000ec4  00000000  00000000  000ba748  2**0
+ >                   CONTENTS, READONLY
+ >   7 .note         00001068  00000ec4  00000ec4  000bb60c  2**0
+ >                   CONTENTS, READONLY
+
+There are obviously 2 non standard ELF sections in the generated object
+file. But first we want to find out what happened to our code in the
+final kernel executable:
+
+ > objdump --disassemble --section=.text vmlinux
+ >
+ > c017e785 <do_con_write+c1> xorl   %edx,%edx
+ > c017e787 <do_con_write+c3> movl   0xc01c7bec,%eax
+ > c017e78c <do_con_write+c8> cmpl   $0x18,0x314(%eax)
+ > c017e793 <do_con_write+cf> je     c017e79f <do_con_write+db>
+ > c017e795 <do_con_write+d1> cmpl   $0xbfffffff,0x40(%esp,1)
+ > c017e79d <do_con_write+d9> ja     c017e7a7 <do_con_write+e3>
+ > c017e79f <do_con_write+db> movl   %edx,%eax
+ > c017e7a1 <do_con_write+dd> movl   0x40(%esp,1),%ebx
+ > c017e7a5 <do_con_write+e1> movb   (%ebx),%dl
+ > c017e7a7 <do_con_write+e3> movzbl %dl,%esi
+
+The whole user memory access is reduced to 10 x86 machine instructions.
+The instructions bracketed in the .section directives are not longer
+in the normal execution path. They are located in a different section 
+of the executable file:
+
+ > objdump --disassemble --section=.fixup vmlinux
+ > 
+ > c0199ff5 <.fixup+10b5> movl   $0xfffffff2,%eax
+ > c0199ffa <.fixup+10ba> xorb   %dl,%dl
+ > c0199ffc <.fixup+10bc> jmp    c017e7a7 <do_con_write+e3>
+
+And finally:
+ > objdump --full-contents --section=__ex_table vmlinux
+ > 
+ >  c01aa7c4 93c017c0 e09f19c0 97c017c0 99c017c0  ................
+ >  c01aa7d4 f6c217c0 e99f19c0 a5e717c0 f59f19c0  ................
+ >  c01aa7e4 080a18c0 01a019c0 0a0a18c0 04a019c0  ................
+
+or in human readable byte order:
+
+ >  c01aa7c4 c017c093 c0199fe0 c017c097 c017c099  ................
+ >  c01aa7d4 c017c2f6 c0199fe9 c017e7a5 c0199ff5  ................
+                               ^^^^^^^^^^^^^^^^^
+                               this is the interesting part!
+ >  c01aa7e4 c0180a08 c019a001 c0180a0a c019a004  ................
+
+What happened? The assembly directives
+
+.section .fixup,"ax"
+.section __ex_table,"a"
+
+told the assembler to move the following code to the specified
+sections in the ELF object file. So the instructions
+3:      movl $-14,%eax
+        xorb %dl,%dl
+        jmp 2b
+ended up in the .fixup section of the object file and the addresses
+        .long 1b,3b
+ended up in the __ex_table section of the object file. 1b and 3b
+are local labels. The local label 1b (1b stands for next label 1 
+backward) is the address of the instruction that might fault, i.e. 
+in our case the address of the label 1 is c017e7a5:
+the original assembly code: > 1:      movb (%ebx),%dl
+and linked in vmlinux     : > c017e7a5 <do_con_write+e1> movb   (%ebx),%dl
+
+The local label 3 (backwards again) is the address of the code to handle
+the fault, in our case the actual value is c0199ff5:
+the original assembly code: > 3:      movl $-14,%eax
+and linked in vmlinux     : > c0199ff5 <.fixup+10b5> movl   $0xfffffff2,%eax
+
+The assembly code
+ > .section __ex_table,"a"
+ >         .align 4
+ >         .long 1b,3b
+
+becomes the value pair
+ >  c01aa7d4 c017c2f6 c0199fe9 c017e7a5 c0199ff5  ................
+                               ^this is ^this is
+                               1b       3b 
+c017e7a5,c0199ff5 in the exception table of the kernel.
+
+So, what actually happens if a fault from kernel mode with no suitable
+vma occurs?
+
+1.) access to invalid address:
+ > c017e7a5 <do_con_write+e1> movb   (%ebx),%dl
+2.) MMU generates exception
+3.) CPU calls do_page_fault
+4.) do page fault calls search_exception_table (regs->eip == c017e7a5);
+5.) search_exception_table looks up the address c017e7a5 in the
+    exception table (i.e. the contents of the ELF section __ex_table 
+    and returns the address of the associated fault handle code c0199ff5.
+6.) do_page_fault modifies its own return address to point to the fault 
+    handle code and returns.
+7.) execution continues in the fault handling code.
+8.) 8a) EAX becomes -EFAULT (== -14)
+    8b) DL  becomes zero (the value we "read" from user space)
+    8c) execution continues at local label 2 (address of the
+        instruction immediately after the faulting user access).
+
+The steps 8a to 8c in a certain way emulate the faulting instruction.
+
+That's it, mostely. If you look at our example, you might ask, why
+we set EAX to -EFAULT in the exception handler code. Well, the
+get_user macro actually returns a value: 0, if the user access was
+successful, -EFAULT on failure. Our original code did not test this
+return value, however the inline assembly code in get_user tries to
+return -EFAULT. GCC selected EAX to return this value.
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX
new file mode 100644
index 000000000..edb8c5212
--- /dev/null
+++ b/Documentation/filesystems/00-INDEX
@@ -0,0 +1,16 @@
+00-INDEX
+	- this file (info on some of the filesystems supported by linux).
+affs.txt
+	- info and mount options for the Amiga Fast File System.
+hpfs.txt
+	- info and mount options for the OS/2 HPFS.
+ncpfs.txt
+	- info on Novell Netware(tm) filesystem using NCP protocol.
+smbfs.txt
+	- info on using filesystems with the SMB protocol (Win 3.11, Win NT)
+sysv-fs.txt
+	- info on the SystemV/Coherent filesystem.
+umsdos.txt
+	- info on the umsdos extensions to the msdos filesystem.
+vfat.txt
+	- info on using the VFAT filesystem used in Win NT and Win 95
diff --git a/Documentation/filesystems/affs.txt b/Documentation/filesystems/affs.txt
new file mode 100644
index 000000000..c5d329ec6
--- /dev/null
+++ b/Documentation/filesystems/affs.txt
@@ -0,0 +1,188 @@
+Amiga filesystems Overview
+==========================
+
+Not all varieties of the Amiga filesystems are supported for reading and
+writing. The Amiga currently knows 6 different filesystems:
+
+DOS\0		The old or original filesystem, not really suited for
+		hard disks and normally not used on them, either.
+		Supported read/write.
+
+DOS\1		The original Fast File System. Supported read/write.
+
+DOS\2		The old "international" filesystem. International means that
+		a bug has been fixed so that accented ("international") letters
+		in file names are case-insensitive, as they ought to be.
+		Supported read/write.
+
+DOS\3		The "international" Fast File System.  Supported read/write.
+
+DOS\4		The original filesystem with directory cache. The directory
+		cache speeds up directory accesses on floppies considerably,
+		but slows down file creation/deletion. Doesn't make much
+		sense on hard disks. Supported read only.
+
+DOS\5		The Fast File System with directory cache. Supported read only.
+
+All of the above filesystems allow block sizes from 512 to 32K bytes.
+Supported block sizes are: 512, 1024, 2048 and 4096 bytes. Larger blocks
+speed up almost everything with the expense of wasted disk space. The speed
+gain above 4K seems not really worth the price, so you don't lose too
+much here, either.
+
+The muFS (multi user File System) equivalents of the above file systems
+are supported, too.
+
+Mount options for the AFFS
+==========================
+
+protect		If this option is set, the protection bits cannot be altered.
+
+uid[=uid]	This sets the uid of the root directory (i. e. the mount point
+		to uid or to the uid of the current user, if the =uid is
+		omitted.
+
+gid[=gid]	Same as above, but for gid.
+
+setuid[=uid]	This sets the owner of all files and directories in the file
+		system to uid or the uid of the current user, respectively.
+
+setgid[=gid]	Same as above, but for gid.
+
+mode=mode	Sets the mode flags to the given (octal) value, regardless
+		of the original permissions. Directories will get an x
+		permission, if the corresponding r bit is set.
+		This is useful since most of the plain AmigaOS files
+		will map to 600.
+
+reserved=num	Sets the number of reserved blocks at the start of the
+		partition to num. Default is 2.
+
+root=block	Sets the block number of the root block. This should never
+		be necessary.
+
+bs=blksize	Sets the blocksize to blksize. Valid block sizes are 512,
+		1024, 2048 and 4096. Like the root option, this should
+		never be necessary, as the affs can figure it out itself.
+
+quiet		The file system will not return an error for disallowed
+		mode changes.
+
+verbose		The volume name, file system type and block size will
+		be written to the syslog.
+
+prefix=path	Path will be prefixed to every absolute path name of
+		symbolic links on an AFFS partition. Default = /
+
+volume=name	When symbolic links with an absolute path are created
+		on an AFFS partition, volume will be prepended as the
+		volume name. Default = "" (empty string).
+
+Handling of the Users/Groups and protection flags
+=================================================
+
+Amiga -> Linux:
+
+The Amiga protection flags RWEDRWEDHSPARWED are handled as follows:
+
+  - R maps to r for user, group and others. On directories, R implies x.
+
+  - If both W and D are allowed, w will be set.
+
+  - If both R and S are set, x will be set.
+
+  - H, P and E are always retained and ignored under Linux.
+
+  - A is always reset when written.
+
+User id and group id will be used unless set[gu]id are given as mount
+options. Since most of the Amiga file systems are single user systems
+they will be owned by root.
+
+Linux -> Amiga:
+
+The Linux rwxrwxrwx file mode is handled as follows:
+
+  - r permission will set R for user, group and others.
+
+  - w permission will set W and D for user, group and others.
+
+  - x permission of the user will set S for plain files.
+
+  - All other flags (suid, sgid, ...) are ignored and will
+    not be retained.
+    
+Newly created files and directories will get the user and group id
+of the current user and a mode according to the umask.
+
+Symbolic links
+==============
+
+Although the Amiga and Linux file systems resemble each other, there
+are some, not always subtle, differences. One of them becomes apparent
+with symbolic links. While Linux has a file system with exactly one
+root directory, the Amiga has a seperate root directory for each
+file system (i. e. partition, floppy disk, ...). With the Amiga,
+these entities are called "volumes". They have symbolic names which
+can be used to access them. Thus, symbolic links can point to a
+different volume. AFFS turns the volume name into a directory name
+and prepends the prefix path (see prefix option) to it.
+
+Example:
+You mount all your Amiga partitions under /amiga/<volume> (where
+<volume> is the name of the volume), and you give the option
+"prefix=/amiga/" when mounting all your AFFS partitions. (They
+might be "User", "WB" and "Graphics", the mount points /amiga/User,
+/amiga/WB and /amiga/Graphics). A symbolic link referring to
+"User:sc/include/dos/dos.h" will be followed to
+"/amiga/User/sc/include/dos/dos.h".
+
+Examples
+========
+
+Command line
+    mount  Archive/Amiga/Workbench3.1.adf /mnt -t affs -o loop,reserved=4
+    mount  /dev/sda3 /Amiga -t affs
+
+/etc/fstab example
+    /dev/sdb5	/d/f    affs    ro
+
+Bugs, Restrictions, Caveats
+===========================
+
+Quite a few things may not work as advertised. Not everything is
+tested, though several hundred MB have been read and written using
+this fs.
+
+Filenames are truncated to 30 characters without warning.
+
+Currently there are no checks against invalid characters (':')
+in filenames.
+
+Case is ignored by the affs in filename matching, but Linux shells
+do care about the case. Example (with /mnt being an affs mounted fs):
+    rm /mnt/WRONGCASE
+will remove /mnt/wrongcase, but
+    rm /mnt/WR*
+will not since the names are matched by the shell.
+
+The block allocation is designed for hard disk partitions. If more
+than 1 process writes to a (small) diskette, the blocks are allocated
+in an ugly way (but the real AFFS doesn't do much better). This
+is also true when space gets tight.
+
+The bitmap valid flag in the root block may not be accurate when the
+system crashes while an affs partition is mounted. There's currently
+no way to fix this without an Amiga (disk validator) or manually
+(who would do this?). Maybe later.
+
+A fsck.affs and mkfs.affs will probably be available in the future.
+Until then, you should do
+    ln -s /bin/true /etc/fs/mkfs.affs
+
+It's not possible to read floppy disks with a normal PC or workstation
+due to an incompatibility with the Amiga floppy controller.
+
+If you are interested in an Amiga Emulator for Linux, look at
+
+http://www-users.informatik.rwth-aachen.de/~crux/uae.html
diff --git a/Documentation/filesystems/hpfs.txt b/Documentation/filesystems/hpfs.txt
new file mode 100644
index 000000000..03e0481bb
--- /dev/null
+++ b/Documentation/filesystems/hpfs.txt
@@ -0,0 +1,27 @@
+Linux can read, but not write, OS/2 HPFS partitions.
+
+Mount options are the same as for msdos partitions.
+
+  uid=nnn	All files in the partition will be owned by user id nnn.
+  gid=nnn	All files in the partition will be in group nnn.
+  umask=nnn	The permission mask (see umask(1)) for the partition.
+  conv=binary   Data is returned exactly as is, with CRLF's.  [default]
+  conv=text     (Carriage return, line feed) is replaced with newline.
+  conv=auto     Chooses, file by file, conv=binary or conv=text (by guessing)
+
+There are mount options unique to HPFS.
+
+  case=lower	Convert file names to lower case.  [default]
+  case=asis     Return file names as is, in mixed case.
+
+  nocheck	Proceed even if "Improperly stopped flag is set"
+
+Case is not significant in filename matching, like real HPFS.
+
+
+Command line example
+    mkdir -p /os2/c
+    mount -t hpfs -o uid=100,gid=100 /dev/sda6 /os2/c
+
+/etc/fstab example
+    /dev/sdb5	/d/f    hpfs    ro,uid=402,gid=402,umask=002
diff --git a/Documentation/filesystems/ncpfs.txt b/Documentation/filesystems/ncpfs.txt
new file mode 100644
index 000000000..8698dba3f
--- /dev/null
+++ b/Documentation/filesystems/ncpfs.txt
@@ -0,0 +1,12 @@
+ncpfs is a filesystem which understands the NCP protocol, designed by the
+Novell Corporation for their NetWare(tm) product. NCP is functionally
+similar to the NFS used in the tcp/ip community.
+To mount a Netware-Filesystem, you need a special mount program, which
+can be found in ncpfs package. Homesite for ncpfs is
+ftp.gwdg.de/pub/linux/misc/ncpfs, but sunsite and its many mirrors
+will have it as well.
+
+Related products are linware and mars_nwe, which will give Linux partial
+NetWare Server functionality.
+Linware's home site is: klokan.sh.cvut.cz/pub/linux/linware,
+Mars_nwe can be found on ftp.gwdg.de/pub/linux/misc/ncpfs.
diff --git a/Documentation/filesystems/smbfs.txt b/Documentation/filesystems/smbfs.txt
new file mode 100644
index 000000000..ffef2d814
--- /dev/null
+++ b/Documentation/filesystems/smbfs.txt
@@ -0,0 +1,13 @@
+smbfs is a filesystem which understands the SMB protocol. This is the
+protocol Windows for Workgroups, Windows NT or Lan Manager use to talk
+to each other. smbfs was inspired by samba, the program written by
+Andrew Tridgell that turns any unix host into a file server for DOS or
+Windows clients.  See ftp://nimbus.anu.edu.au/pub/tridge/samba/ for
+this interesting program suite and lots of more information on SMB and
+NetBIOS over TCP/IP. There you also find explanation for concepts like
+netbios name or share.
+
+To use smbfs, you need a special mount program, which can be found in
+the ksmbfs package, found on
+sunsite.unc.edu:/pub/Linux/system/Filesystems/smbfs.
+
diff --git a/Documentation/filesystems/sysv-fs.txt b/Documentation/filesystems/sysv-fs.txt
new file mode 100644
index 000000000..d6ba74af0
--- /dev/null
+++ b/Documentation/filesystems/sysv-fs.txt
@@ -0,0 +1,37 @@
+This is the implementation of the SystemV/Coherent filesystem for Linux.
+It implements all of
+  - Xenix FS,
+  - SystemV/386 FS,
+  - Coherent FS.
+
+This is version beta 4.
+
+To install:
+* Answer the 'System V and Coherent filesystem support' question with 'y'
+  when configuring the kernel.
+* To mount a disk or a partition, use
+    mount [-r] -t sysv device mountpoint
+  The file system type names
+               -t sysv
+               -t xenix
+               -t coherent
+  may be used interchangeably, but the last two will eventually disappear.
+
+Bugs in the present implementation:
+- Coherent FS:
+  - The "free list interleave" n:m is currently ignored.
+  - Only file systems with no filesystem name and no pack name are recognized.
+  (See Coherent "man mkfs" for a description of these features.)
+- SystemV Release 2 FS:
+  The superblock is only searched in the blocks 9, 15, 18, which corresponds to the
+  beginning of track 1 on floppy disks. No support for this FS on hard disk yet.
+
+
+Please report any bugs and suggestions to
+  Bruno Haible <haible@ma2s2.mathematik.uni-karlsruhe.de> or
+  Pascal Haible <haible@izfm.uni-stuttgart.de> .
+
+
+Bruno Haible
+<haible@ma2s2.mathematik.uni-karlsruhe.de>
+
diff --git a/Documentation/filesystems/umsdos.txt b/Documentation/filesystems/umsdos.txt
new file mode 100644
index 000000000..320dac6ca
--- /dev/null
+++ b/Documentation/filesystems/umsdos.txt
@@ -0,0 +1,96 @@
+Very short explanation for the impatient!!!
+
+Umsdos is a file system driver that run on top the MSDOS fs driver.
+It is written by Jacques Gelinas (jacques@solucorp.qc.ca)
+
+Umsdos is not a file system per se, but a twist to make a boring
+one into a useful one.
+
+It gives you:
+
+	long file name
+	Permissions and owner
+	Links
+	Special files (devices, pipe...)
+	All is need to be a linux root fs.
+
+There is plenty of documentation on it in the source. A formated document
+made from those comments is available from
+sunsite.unc.edu:/pub/Linux/system/Filesystems/umsdos.
+
+Mostly...
+
+You mount a DOS partition like this
+
+mount -t umsdos /dev/hda3 /mnt
+         ^
+---------|
+
+All option are passed to the msdos drivers. Option like uid,gid etc are
+given to msdos.
+
+The default behavior of Umsdos is to do the same thing as the msdos driver
+mostly passing commands to it without much processing. Again, this is
+the default. After doing the mount on a DOS partition, nothing special
+happen. This is why all mount options are passed to the Msdos fs driver.
+
+Umsdos use a special DOS file --linux-.--- to store the information
+which can't be handle by the normal MsDOS file system. This is the trick.
+
+--linux-.--- is optional. There is one per directory.
+
+**** If --linux-.--- is missing, then Umsdos process the directory the
+     same way the msdos driver do. Short file name, no goodies, default
+     owner and permissions. So each directory may have or not this
+     --linux-.---
+
+Now, how to get those --linux-.---.
+
+\begin joke_section
+
+	Well send me a directory content
+	and I will send you one customised for you.
+	$5 per directory. Add any applicable taxes.
+\end joke_section
+
+A utility umssync creates those. The kernel maintain them. It is available
+from the same directory above (sunsite) in the file umsdos_progs-0.7.tar.gz.
+A compiled version is available in umsdos_progs-0.7.bin.tar.gz.
+
+So in our example, after mounting mnt, we do
+
+umssync .
+
+This will promote this directory (a recursive option is available) to full
+umsdos capabilities (long name ...). A ls -l before and after won't show
+much difference however. The file which were there are still there. But now
+you can do all this:
+
+	chmod 644 *
+	chown you.your_groupe *
+	ls >THIS_IS.A.VERY.LONG.NAME
+	ln -s toto tata
+	ls -l
+
+Once a directory is promoted, all subdirectory created will inherit that
+promotion.
+
+What happen if you boot DOS and create files in those promoted directories ?
+Umsdos won't notice new files, but will signal removed file (it won't crash).
+Using umssync in /etc/rc will make sure the DOS directory is in sync with
+the --linux-.---.
+
+It is a good idea to put the following command in your RC file just
+after the "mount -a":
+
+	mount -a
+	/sbin/umssync -i+ -c+ -r99 /umsdos_mount_point
+
+	(You put one for each umsdos mount point in the fstab)
+
+This will insure nice operation. A umsdos.fsck is in the making,
+so you will be allowed to managed umsdos partition in the same way
+other filesystem are, using the generic fsck front end.
+
+Hope this helps!
+
diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt
new file mode 100644
index 000000000..6f03cc799
--- /dev/null
+++ b/Documentation/filesystems/vfat.txt
@@ -0,0 +1,464 @@
+USING VFAT
+----------------------------------------------------------------------
+To use the vfat filesystem, use the filesystem type 'vfat'.  i.e.
+  mount -t vfat /dev/fd0 /mnt
+
+No special partition formatter is required.  mkdosfs will work fine
+if you want to format from within Linux.
+
+VFAT MOUNT OPTIONS
+----------------------------------------------------------------------
+uni_xlate     -- Translate unhandled Unicode characters to special
+		 escaped sequences.  This would let you backup and
+		 restore filenames that are created with any Unicode
+		 characters.  Until Linux supports Unicode for real,
+		 this gives you an alternative.  Without this option,
+		 a '?' is used when no translation is possible.  The
+		 escape character is ':' because it is otherwise
+		 illegal on the vfat filesystem.  The escape sequence
+		 that gets used, where u is the unicode character, is:
+			':', (u & 0x3f), ((u>>6) & 0x3f), (u>>12),
+posix         -- Allow names of same letters, different case such as
+                 'LongFileName' and 'longfilename' to coexist.  This has some
+                 problems currently because 8.3 conflicts are not handled
+                 correctly for Posix filesystem compliance.
+nonumtail     -- When creating 8.3 aliases, normally the alias will
+                 end in '~1' or tilde followed by some number.  If this
+                 option is set, then if the filename is 
+                 "longfilename.txt" and "longfile.txt" does not
+                 currently exist in the directory, 'longfile.txt' will
+                 be the short alias instead of 'longfi~1.txt'. 
+                  
+quiet         -- Stops printing certain warning messages.
+
+
+TODO
+----------------------------------------------------------------------
+* Need to get rid of the raw scanning stuff.  Instead, always use
+  a get next directory entry approach.  The only thing left that uses
+  raw scanning is the directory renaming code.
+
+* Need to add dcache_lookup code msdos filesystem.  This means the
+  directories need to be versioned like the vfat filesystem.
+
+* Add support for different codepages.  Right now, we only support
+  the a single English codepage.
+
+* Fix the Posix filesystem support to work in 8.3 space.  This involves
+  renaming aliases if a conflict occurs between a new filename and
+  an old alias.  This is quite a mess.
+
+
+POSSIBLE PROBLEMS
+----------------------------------------------------------------------
+* vfat_valid_longname does not properly checked reserved names.
+* When a volume name is the same as a directory name in the root
+  directory of the filesystem, the directory name sometimes shows
+  up empty an empty file.
+
+BUG REPORTS
+----------------------------------------------------------------------
+If you have trouble with the VFAT filesystem, mail bug reports to
+chaffee@bugs-bunny.cs.berkeley.edu.  Please specify the filename
+and the operation that gave you trouble.
+
+TEST SUITE
+----------------------------------------------------------------------
+If you plan to make any modifications to the vfat filesystem, please
+get the test suite that comes with the vfat distribution at
+
+  http://www-plateau.cs.berkeley.edu/people/chaffee/vfat.html
+
+This tests quite a few parts of the vfat filesystem and additional
+tests for new features or untested features would be appreciated.
+
+NOTES ON THE STRUCTURE OF THE VFAT FILESYSTEM
+----------------------------------------------------------------------
+(This documentation was provided by Galen C. Hunt <gchunt@cs.rochester.edu>
+ and lightly annotated by Gordon Chaffee).
+
+This document presents a very rough, technical overview of my
+knowledge of the extended FAT file system used in Windows NT 3.5 and
+Windows 95.  I don't guarantee that any of the following is correct,
+but it appears to be so.
+
+The extended FAT file system is almost identical to the FAT
+file system used in DOS versions up to and including 6.223410239847
+:-).  The significant change has been the addition of long file names.
+Theses names support up to 255 characters including spaces and lower
+case characters as opposed to the traditional 8.3 short names.
+
+Here is the description of the traditional FAT entry in the current
+Windows 95 filesystem:
+
+        struct directory { // Short 8.3 names 
+                unsigned char name[8];          // file name 
+                unsigned char ext[3];           // file extension 
+                unsigned char attr;             // attribute byte 
+		unsigned char lcase;		// Case for base and extension
+		unsigned char ctime_ms;		// Creation time, milliseconds
+		unsigned char ctime[2];		// Creation time
+		unsigned char cdate[2];		// Creation date
+		unsigned char adate[2];		// Last access date
+		unsigned char reserved[2];	// reserved values (ignored) 
+                unsigned char time[2];          // time stamp 
+                unsigned char date[2];          // date stamp 
+                unsigned char start[2];         // starting cluster number 
+                unsigned char size[4];          // size of the file 
+        };
+
+The lcase field specifies if the base and/or the extension of an 8.3
+name should be capitalized.  This field does not seem to be used by
+Windows 95 but it is used by Windows NT.  The case of filenames is not
+completely compatible from Windows NT to Windows 95.  It is not completely
+compatible in the reverse direction, however.  Filenames that fit in
+the 8.3 namespace and are written on Windows NT to be lowercase will
+show up as uppercase on Windows 95.
+
+Note that the "start" and "size" values are actually little
+endian integer values.  The descriptions of the fields in this
+structure are public knowledge and can be found elsewhere.
+
+With the extended FAT system, Microsoft has inserted extra
+directory entries for any files with extended names.  (Any name which
+legally fits within the old 8.3 encoding scheme does not have extra
+entries.)  I call these extra entries slots.  Basically, a slot is a
+specially formatted directory entry which holds up to 13 characters of
+a files extended name.  Think of slots as additional labeling for the
+directory entry of the file to which they correspond.  Microsoft
+prefers to refer to the 8.3 entry for a file as its alias and the
+extended slot directory entries as the file name. 
+
+The C structure for a slot directory entry follows:
+
+        struct slot { // Up to 13 characters of a long name 
+                unsigned char id;               // sequence number for slot 
+                unsigned char name0_4[10];      // first 5 characters in name 
+                unsigned char attr;             // attribute byte
+                unsigned char reserved;         // always 0 
+                unsigned char alias_checksum;   // checksum for 8.3 alias 
+                unsigned char name5_10[12];     // 6 more characters in name
+                unsigned char start[2];         // starting cluster number
+                unsigned char name11_12[4];     // last 2 characters in name
+        };
+
+If the layout of the slots looks a little odd, it's only
+because of Microsoft's efforts to maintain compatibility with old
+software.  The slots must be disguised to prevent old software from
+panicing.  To this end, a number of measures are taken:
+
+        1) The attribute byte for a slot directory entry is always set
+           to 0x0f.  This corresponds to an old directory entry with
+           attributes of "hidden", "system", "read-only", and "volume
+           label".  Most old software will ignore any directory
+           entries with the "volume label" bit set.  Real volume label
+           entries don't have the other three bits set.
+
+        2) The starting cluster is always set to 0, an impossible
+           value for a DOS file.
+
+Because the extended FAT system is backward compatible, it is
+possible for old software to modify directory entries.  Measures must
+be taken to insure the validity of slots.  An extended FAT system can
+verify that a slot does in fact belong to an 8.3 directory entry by
+the following:
+
+        1) Positioning.  Slots for a file always immediately proceed
+           their corresponding 8.3 directory entry.  In addition, each
+           slot has an id which marks its order in the extended file
+           name.  Here is a very abbreviated view of an 8.3 directory
+           entry and its corresponding long name slots for the file
+           "My Big File.Extension which is long":
+
+                <proceeding files...>
+                <slot #3, id = 0x43, characters = "h is long">
+                <slot #2, id = 0x02, characters = "xtension whic">
+                <slot #1, id = 0x01, characters = "My Big File.E">
+                <directory entry, name = "MYBIGFIL.EXT">
+
+           Note that the slots are stored from last to first.  Slots
+           are numbered from 1 to N.  The Nth slot is or'ed with 0x40
+           to mark it as the last one.
+
+        2) Checksum.  Each slot has an "alias_checksum" value.  The
+           checksum is calculated from the 8.3 name using the
+           following algorithm:
+
+                for (sum = i = 0; i < 11; i++) {
+                        sum = (((sum&1)<<7)|((sum&0xfe)>>1)) + name[i]
+                }
+
+	3) If there is in the final slot, a Unicode NULL (0x0000) is stored
+           after the final character.  After that, all unused characters in
+           the final slot are set to Unicode 0xFFFF.
+
+Finally, note that the extended name is stored in Unicode.  Each Unicode
+character takes two bytes.
+
+
+NOTES ON UNICODE TRANSLATION IN VFAT FILESYSTEM
+----------------------------------------------------------------------
+(Information provided by Steve Searle <steve@mgu.bath.ac.uk>)
+
+Char used as   Char(s) used   Char(s) used in     Entries which have
+filename       in shortname   longname slot       been corrected
+0x80 (128)     0x80           0xC7                   
+0x81 (129)     0x9A           0xFC
+0x82 (130)     0x90           0xE9                     E
+0x83 (131)     0xB6           0xE2                     E
+0x84 (132)     0x8E           0xE4                     E
+0x85 (133)     0xB7           0xE0                     E
+0x86 (134)     0x8F           0xE5                     E
+0x87 (135)     0x80           0xE7                     E
+0x88 (136)     0xD2           0xEA                     E
+0x89 (137)     0xD3           0xEB                     E
+0x8A (138)     0xD4           0xE8                     E
+0x8B (139)     0xD8           0xEF                     E
+0x8C (140)     0xD7           0xEE                     E
+0x8D (141)     0xDE           0xEC                     E
+0x8E (142)     0x8E           0xC4                     E
+0x8F (143)     0x8F           0xC5                     E
+0x90 (144)     0x90           0xC9                     E
+0x91 (145)     0x92           0xE6                     E
+0x92 (146)     0x92           0xC6                     E
+0x93 (147)     0xE2           0xF4                     E
+0x94 (148)     0x99           0xF6
+0x95 (149)     0xE3           0xF2
+0x96 (150)     0xEA           0xFB
+0x97 (151)     0xEB           0xF9
+0x98 (152)     "_~1"          0xFF
+0x99 (153)     0x99           0xD6
+0x9A (154)     0x9A           0xDC
+0x9B (155)     0x9D           0xF8
+0x9C (156)     0x9C           0xA3
+0x9D (157)     0x9D           0xD8
+0x9E (158)     0x9E           0xD7
+0x9F (159)     0x9F           0x92
+0xA0 (160)     0xB5           0xE1
+0xA1 (161)     0xD6           0xE0
+0xA2 (162)     0xE0           0xF3
+0xA3 (163)     0xE9           0xFA
+0xA4 (164)     0xA5           0xF1
+0xA5 (165)     0xA5           0xD1
+0xA6 (166)     0xA6           0xAA
+0xA7 (167)     0xA7           0xBA
+0xA8 (168)     0xA8           0xBF
+0xA9 (169)     0xA9           0xAE
+0xAA (170)     0xAA           0xAC
+0xAB (171)     0xAB           0xBD
+0xAC (172)     0xAC           0xBC
+0xAD (173)     0xAD           0xA1
+0xAE (174)     0xAE           0xAB
+0xAF (175)     0xAF           0xBB
+0xB0 (176)     0xB0           0x91 0x25
+0xB1 (177)     0xB1           0x92 0x25
+0xB2 (178)     0xB2           0x93 0x25
+0xB3 (179)     0xB3           0x02 0x25
+0xB4 (180)     0xB4           0x24 0x25
+0xB5 (181)     0xB5           0xC1
+0xB6 (182)     0xB6           0xC2
+0xB7 (183)     0xB7           0xC0
+0xB8 (184)     0xB8           0xA9
+0xB9 (185)     0xB9           0x63 0x25
+0xBA (186)     0xBA           0x51 0x25
+0xBB (187)     0xBB           0x57 0x25
+0xBC (188)     0xBC           0x5D 0x25
+0xBD (189)     0xBD           0xA2
+0xBE (190)     0xBE           0xA5
+0xBF (191)     0xBF           0x10 0x25
+0xC0 (192)     0xC0           0x14 0x25
+0xC1 (193)     0xC1           0x34 0x25
+0xC2 (194)     0xC2           0x2C 0x25
+0xC3 (195)     0xC3           0x1C 0x25
+0xC4 (196)     0xC4           0x00 0x25
+0xC5 (197)     0xC5           0x3C 0x25
+0xC6 (198)     0xC7           0xE3                     E
+0xC7 (199)     0xC7           0xC3
+0xC8 (200)     0xC8           0x5A 0x25                E
+0xC9 (201)     0xC9           0x54 0x25                E
+0xCA (202)     0xCA           0x69 0x25                E
+0xCB (203)     0xCB           0x66 0x25                E
+0xCC (204)     0xCC           0x60 0x25                E
+0xCD (205)     0xCD           0x50 0x25                E
+0xCE (206)     0xCE           0x6C 0x25                E
+0xCF (207)     0xCF           0xA4                     E
+0xD0 (208)     0xD1           0xF0
+0xD1 (209)     0xD1           0xD0
+0xD2 (210)     0xD2           0xCA
+0xD3 (211)     0xD3           0xCB
+0xD4 (212)     0xD4           0xC8
+0xD5 (213)     0x49           0x31 0x01
+0xD6 (214)     0xD6           0xCD
+0xD7 (215)     0xD7           0xCE
+0xD8 (216)     0xD8           0xCF
+0xD9 (217)     0xD9           0x18 0x25
+0xDA (218)     0xDA           0x0C 0x25
+0xDB (219)     0xDB           0x88 0x25
+0xDC (220)     0xDC           0x84 0x25
+0xDD (221)     0xDD           0xA6
+0xDE (222)     0xDE           0xCC
+0xDF (223)     0xDF           0x80 0x25
+0xE0 (224)     0xE0           0xD3
+0xE1 (225)     0xE1           0xDF
+0xE2 (226)     0xE2           0xD4
+0xE3 (227)     0xE3           0xD2
+0xE4 (228)     0x05           0xF5
+0xE5 (229)     0x05           0xD5
+0xE6 (230)     0xE6           0xB5
+0xE7 (231)     0xE8           0xFE
+0xE8 (232)     0xE8           0xDE
+0xE9 (233)     0xE9           0xDA
+0xEA (234)     0xEA           0xDB
+0xEB (235)     0xEB           0xD9
+0xEC (236)     0xED           0xFD
+0xED (237)     0xED           0xDD
+0xEE (238)     0xEE           0xAF
+0xEF (239)     0xEF           0xB4
+0xF0 (240)     0xF0           0xAD
+0xF1 (241)     0xF1           0xB1
+0xF2 (242)     0xF2           0x17 0x20
+0xF3 (243)     0xF3           0xBE
+0xF4 (244)     0xF4           0xB6
+0xF5 (245)     0xF5           0xA7
+0xF6 (246)     0xF6           0xF7
+0xF7 (247)     0xF7           0xB8
+0xF8 (248)     0xF8           0xB0
+0xF9 (249)     0xF9           0xA8
+0xFA (250)     0xFA           0xB7
+0xFB (251)     0xFB           0xB9
+0xFC (252)     0xFC           0xB3
+0xFD (253)     0xFD           0xB2
+0xFE (254)     0xFE           0xA0 0x25
+0xFF (255)     0xFF           0xA0
+
+
+Page 0
+0x80 (128)     0x00
+0x81 (129)     0x00
+0x82 (130)     0x00
+0x83 (131)     0x00
+0x84 (132)     0x00
+0x85 (133)     0x00
+0x86 (134)     0x00
+0x87 (135)     0x00
+0x88 (136)     0x00
+0x89 (137)     0x00
+0x8A (138)     0x00
+0x8B (139)     0x00
+0x8C (140)     0x00
+0x8D (141)     0x00
+0x8E (142)     0x00
+0x8F (143)     0x00
+0x90 (144)     0x00
+0x91 (145)     0x00
+0x92 (146)     0x00
+0x93 (147)     0x00
+0x94 (148)     0x00
+0x95 (149)     0x00
+0x96 (150)     0x00
+0x97 (151)     0x00
+0x98 (152)     0x00
+0x99 (153)     0x00
+0x9A (154)     0x00
+0x9B (155)     0x00
+0x9C (156)     0x00
+0x9D (157)     0x00
+0x9E (158)     0x00
+0x9F (159)     0x92
+0xA0 (160)     0xFF
+0xA1 (161)     0xAD
+0xA2 (162)     0xBD
+0xA3 (163)     0x9C
+0xA4 (164)     0xCF
+0xA5 (165)     0xBE
+0xA6 (166)     0xDD
+0xA7 (167)     0xF5
+0xA8 (168)     0xF9
+0xA9 (169)     0xB8
+0xAA (170)     0x00
+0xAB (171)     0xAE
+0xAC (172)     0xAA
+0xAD (173)     0xF0
+0xAE (174)     0x00
+0xAF (175)     0xEE
+0xB0 (176)     0xF8
+0xB1 (177)     0xF1
+0xB2 (178)     0xFD
+0xB3 (179)     0xFC
+0xB4 (180)     0xEF
+0xB5 (181)     0xE6
+0xB6 (182)     0xF4
+0xB7 (183)     0xFA
+0xB8 (184)     0xF7
+0xB9 (185)     0xFB
+0xBA (186)     0x00
+0xBB (187)     0xAF
+0xBC (188)     0xAC
+0xBD (189)     0xAB
+0xBE (190)     0xF3
+0xBF (191)     0x00
+0xC0 (192)     0xB7
+0xC1 (193)     0xB5
+0xC2 (194)     0xB6
+0xC3 (195)     0xC7
+0xC4 (196)     0x8E
+0xC5 (197)     0x8F
+0xC6 (198)     0x92
+0xC7 (199)     0x80
+0xC8 (200)     0xD4
+0xC9 (201)     0x90
+0xCA (202)     0xD2
+0xCB (203)     0xD3
+0xCC (204)     0xDE
+0xCD (205)     0xD6
+0xCE (206)     0xD7
+0xCF (207)     0xD8
+0xD0 (208)     0x00
+0xD1 (209)     0xA5
+0xD2 (210)     0xE3
+0xD3 (211)     0xE0
+0xD4 (212)     0xE2
+0xD5 (213)     0xE5
+0xD6 (214)     0x99
+0xD7 (215)     0x9E
+0xD8 (216)     0x9D
+0xD9 (217)     0xEB
+0xDA (218)     0xE9
+0xDB (219)     0xEA
+0xDC (220)     0x9A
+0xDD (221)     0xED
+0xDE (222)     0xE8
+0xDF (223)     0xE1
+0xE0 (224)     0x85, 0xA1
+0xE1 (225)     0xA0
+0xE2 (226)     0x83
+0xE3 (227)     0xC6
+0xE4 (228)     0x84
+0xE5 (229)     0x86
+0xE6 (230)     0x91
+0xE7 (231)     0x87
+0xE8 (232)     0x8A
+0xE9 (233)     0x82
+0xEA (234)     0x88
+0xEB (235)     0x89
+0xEC (236)     0x8D
+0xED (237)     0x00
+0xEE (238)     0x8C
+0xEF (239)     0x8B
+0xF0 (240)     0xD0
+0xF1 (241)     0xA4
+0xF2 (242)     0x95
+0xF3 (243)     0xA2
+0xF4 (244)     0x93
+0xF5 (245)     0xE4
+0xF6 (246)     0x94
+0xF7 (247)     0xF6
+0xF8 (248)     0x9B
+0xF9 (249)     0x97
+0xFA (250)     0xA3
+0xFB (251)     0x96
+0xFC (252)     0x81
+0xFD (253)     0xEC
+0xFE (254)     0xE7
+0xFF (255)     0x98
+
diff --git a/Documentation/ide.txt b/Documentation/ide.txt
new file mode 100644
index 000000000..09a969f5c
--- /dev/null
+++ b/Documentation/ide.txt
@@ -0,0 +1,482 @@
+ide.txt -- Information regarding the Enhanced IDE drive in Linux 2.1.xx
+===============================================================================
+Supported by:
+	Mark Lord    <mlord@pobox.com>		-- disks, interfaces, probing
+	Gadi Oxman   <gadio@netvision.net.il>	-- tapes, disks, whatever
+	Scott Snyder <snyder@fnald0.fnal.gov>	-- cdroms, ATAPI, audio
+
+   +-----------------------------------------------------------------+
+   |  The hdparm utility for controlling various IDE features is     |
+   |  packaged separately.  Look for it on popular linux FTP sites.  |
+   +-----------------------------------------------------------------+
+
+See description later on below for handling BIG IDE drives with >1024 cyls.
+
+Major features of the 2.1.xx IDE driver ("NEW!" marks changes since 2.0.xx):
+
+NEW!	- support for IDE ATAPI *floppy* drives
+	- support for IDE ATAPI *tape* drives, courtesy of Gadi Oxman
+		(re-run MAKEDEV.ide to create the tape device entries in /dev/)
+	- support for up to *four* IDE interfaces on one or more IRQs
+	- support for any mix of up to *eight* IDE drives
+	- support for reading IDE ATAPI cdrom drives (NEC,MITSUMI,VERTOS,SONY)
+	- support for audio functions
+	- auto-detection of interfaces, drives, IRQs, and disk geometries
+		- "single" drives should be jumpered as "master", not "slave"
+		  (both are now probed for)
+	- support for BIOSs which report "more than 16 heads" on disk drives
+	- uses LBA (slightly faster) on disk drives which support it
+	- support for lots of fancy (E)IDE drive functions with hdparm utility
+	- optional (compile time) support for 32-bit VLB data transfers
+	- support for IDE multiple (block) mode (same as hd.c)
+	- support for interrupt unmasking during I/O (better than hd.c)
+	- improved handshaking and error detection/recovery
+	- can co-exist with hd.c controlling the first interface
+	- run-time selectable 32bit interface support (using hdparm-2.3)
+	- support for reliable operation of buggy RZ1000 interfaces
+		- PCI support is automatic when rz1000 support is configured
+	- support for reliable operation of buggy CMD-640 interfaces
+		- PCI support is automatic when cmd640 support is configured
+		- for VLB, use kernel command line option:   ide0=cmd640_vlb
+		- this support also enables the secondary i/f when needed
+		- interface PIO timing & prefetch parameter support
+	- experimental support for UMC 8672 interfaces
+	- support for secondary interface on the FGI/Holtek HT-6560B VLB i/f
+		- use kernel command line option:   ide0=ht6560
+	- experimental support for various IDE chipsets
+		- use appropriate kernel command line option from list below
+	- support for drives with a stuck WRERR_STAT bit
+	- support for removable devices, including door lock/unlock
+	- transparent support for DiskManager 6.0x and "Dynamic Disk Overlay"
+	- works with Linux fdisk, LILO, loadlin, bootln, etc..
+	- mostly transparent support for EZ-Drive disk translation software
+		- to use LILO with EZ, install LILO on the linux partition
+		  rather than on the master boot record, and then mark the
+		  linux partition as "bootable" or "active" using fdisk.
+		  (courtesy of Juha Laiho <jlaiho@ichaos.nullnet.fi>).
+	- auto-detect of disk translations by examining partition table
+	- ide-cd.c now compiles separate from ide.c
+	- Bus-Master DMA support for Intel PCI Triton chipset IDE interfaces
+		- for details, see comments at top of triton.c
+	- ide-cd.c now supports door locking and auto-loading.
+		- Also preliminary support for multisession
+		  and direct reads of audio data.
+	- experimental support for Promise DC4030VL caching interface card
+		- email thanks/problems to: peterd@pnd-pc.demon.co.uk
+	- the hdparm-3.1 package can be used to set PIO modes for some chipsets.
+NEW!	- support for the OPTi 82C621 chipset, courtesy of Jaromir Koutek.
+NEW!	- support for loadable modules
+
+
+For work in progress, see the comments in ide.c, ide-cd.c, triton.c, ...
+
+***  IMPORTANT NOTICES:  BUGGY IDE CHIPSETS CAN CORRUPT DATA!!
+***  =================
+***  PCI versions of the CMD640 and RZ1000 interfaces are now detected
+***  automatically at startup when PCI BIOS support is configured.
+***
+***  Linux disables the "prefetch" ("readahead") mode of the RZ1000
+***  to prevent data corruption possible due to hardware design flaws.
+***
+***  For the CMD640, linux disables "IRQ unmasking" (hdparm -u1) on any
+***  drive for which the "prefetch" mode of the CMD640 is turned on.
+***  If "prefetch" is disabled (hdparm -p8), then "IRQ unmasking" can be
+***  used again.
+***
+***  For the CMD640, linux disables "32bit I/O" (hdparm -c1) on any drive
+***  for which the "prefetch" mode of the CMD640 is turned off.
+***  If "prefetch" is enabled (hdparm -p9), then "32bit I/O" can be
+***  used again.
+***
+***  The CMD640 is also used on some Vesa Local Bus (VLB) cards, and is *NOT*
+***  automatically detected by Linux.  For safe, reliable operation with such
+***  interfaces, one *MUST* use the "ide0=cmd640_vlb" kernel option.
+***
+***  Use of the "serialize" option is no longer necessary.
+
+This is the multiple IDE interface driver, as evolved from hd.c.
+It supports up to four IDE interfaces, on one or more IRQs (usually 14 & 15).
+There can be up to two drives per interface, as per the ATA-2 spec.
+
+Primary:    ide0, port 0x1f0; major=3;  hda is minor=0; hdb is minor=64
+Secondary:  ide1, port 0x170; major=22; hdc is minor=0; hdd is minor=64
+Tertiary:   ide2, port 0x1e8; major=33; hde is minor=0; hdf is minor=64
+Quaternary: ide3, port 0x168; major=34; hdg is minor=0; hdh is minor=64
+
+To access devices on the 2nd/3rd/4th interfaces, device entries must first be
+created in /dev for them.  To create such entries, simply run the included
+shell script:   /usr/src/linux/scripts/MAKEDEV.ide
+
+Apparently many releases of Slackware 2.2/2.3 have incorrect entries
+in /dev for hdc* and hdd* -- this can also be corrected by running MAKEDEV.ide
+
+ide.c automatically probes for the primary and secondary interfaces,
+for the drives/geometries attached to those interfaces, and for the
+IRQ numbers being used by the interfaces (normally IRQ14 & IRQ15).
+
+Interfaces beyond the first two are not normally probed for, but may be
+specified using kernel "command line" options.  For example,
+
+	ide3=0x168,0x36e,10	/* ioports 0x168-0x16f,0x36e, irq 10 */
+
+Normally the irq number need not be specified, as ide.c will probe for it:
+
+	ide3=0x168,0x36e	/* ioports 0x168-0x16f,0x36e */
+
+The standard port, and irq values are these:
+
+	ide0=0x1f0,0x3f6,14
+	ide1=0x170,0x376,15
+	ide2=0x1e8,0x3ee,11
+	ide3=0x168,0x36e,10
+
+Note that the first parameter reserves 8 contiguous ioports, whereas the
+second value denotes a single ioport. If in doubt, do a 'cat /proc/ioports'.
+
+In all probability the device uses these ports and irqs if it is attached
+to the appropriate ide channel.  Pass the parameter for the correct ide
+channel to the kernel, as explained above.
+
+Any number of interfaces may share a single IRQ if necessary, at a slight
+performance penalty, whether on separate cards or a single VLB card.
+The IDE driver automatically detects and handles this.  However, this may
+or may not be harmful to your hardware.. two or more cards driving the same IRQ
+can potentially burn each other's bus driver, though in practice this
+seldom occurs.  Be careful, and if in doubt, don't do it!
+
+Drives are normally found by auto-probing and/or examining the CMOS/BIOS data.
+For really weird situations, the apparent (fdisk) geometry can also be specified
+on the kernel "command line" using LILO.  The format of such lines is:
+
+	hdx=cyls,heads,sects,wpcom,irq
+or	hdx=cdrom
+
+where hdx can be any of hda through hdh, Three values are required
+(cyls,heads,sects).  For example:
+
+	hdc=1050,32,64  hdd=cdrom
+
+either {hda,hdb} or {hdc,hdd}.  The results of successful auto-probing may
+override the physical geometry/irq specified, though the "original" geometry
+may be retained as the "logical" geometry for partitioning purposes (fdisk).
+
+If the auto-probing during boot time confuses a drive (ie. the drive works
+with hd.c but not with ide.c), then an command line option may be specified
+for each drive for which you'd like the drive to skip the hardware
+probe/identification sequence.  For example:
+
+	hdb=noprobe
+or
+	hdc=768,16,32
+	hdc=noprobe
+
+Note that when only one IDE device is attached to an interface,
+it should be jumpered as "single" or "master", *not* "slave".
+Many folks have had "trouble" with cdroms because of this requirement,
+so ide.c now probes for both units, though success is more likely
+when the drive is jumpered correctly.
+
+Courtesy of Scott Snyder, the driver supports ATAPI cdrom drives
+such as the NEC-260 and the new MITSUMI triple/quad speed drives.
+Such drives will be identified at boot time, just like a harddisk.
+
+If for some reason your cdrom drive is *not* found at boot time, you can force
+the probe to look harder by supplying a kernel command line parameter
+via LILO, such as:
+
+	hdc=cdrom	/* hdc = "master" on second interface */
+or
+	hdd=cdrom	/* hdd = "slave" on second interface */
+
+For example, a GW2000 system might have a harddrive on the primary
+interface (/dev/hda) and an IDE cdrom drive on the secondary interface
+(/dev/hdc).  To mount a CD in the cdrom drive, one would use something like:
+
+	ln -sf /dev/hdc /dev/cdrom
+	mkdir /cd
+	mount /dev/cdrom /cd -t iso9660 -o ro
+
+If, after doing all of the above, mount doesn't work and you see
+errors from the driver (with dmesg) complaining about `status=0xff',
+this means that the hardware is not responding to the driver's attempts
+to read it.  One of the following is probably the problem:
+
+  - Your hardware is broken.
+
+  - You are using the wrong address for the device, or you have the
+    drive jumpered wrong.  Review the configuration instructions above.
+
+  - Your IDE controller requires some nonstandard initialization sequence
+    before it will work properly.  If this is the case, there will often
+    be a separate MS-DOS driver just for the controller.  IDE interfaces
+    on sound cards usually fall into this category.  Such configurations
+    can often be made to work by first booting MS-DOS, loading the
+    appropriate drivers, and then warm-booting linux (without powering
+    off).  This can be automated using loadlin in the MS-DOS autoexec.
+
+If you always get timeout errors, interrupts from the drive are probably
+not making it to the host.  Check how you have the hardware jumpered
+and make sure it matches what the driver expects (see the configuration
+instructions above).  If you have a PCI system, also check the BIOS
+setup; i've had one report of a system which was shipped with IRQ 15
+disabled by the BIOS.
+
+The kernel is able to execute binaries directly off of the cdrom,
+provided it is mounted with the default block size of 1024 (as above).
+
+Please pass on any feedback on the cdrom stuff to the author & maintainer,
+Scott Snyder (snyder@fnald0.fnal.gov).
+
+Note that if BOTH hd.c and ide.c are configured into the kernel,
+hd.c will normally be allowed to control the primary IDE interface.
+This is useful for older hardware that may be incompatible with ide.c,
+and still allows newer hardware to run on the 2nd/3rd/4th IDE ports
+under control of ide.c.   To have ide.c also "take over" the primary
+IDE port in this situation, use the "command line" parameter:  ide0=0x1f0
+
+mlord@pobox.com
+snyder@fnald0.fnal.gov
+================================================================================
+
+Summary of ide driver parameters for kernel "command line":
+----------------------------------------------------------
+ "hdx="  is recognized for all "x" from "a" to "h", such as "hdc".
+ "idex=" is recognized for all "x" from "0" to "3", such as "ide1".
+
+ "hdx=noprobe"		: drive may be present, but do not probe for it
+ "hdx=none"		: drive is NOT present, ignore cmos and do not probe
+ "hdx=nowerr"		: ignore the WRERR_STAT bit on this drive
+ "hdx=cdrom"		: drive is present, and is a cdrom drive
+ "hdx=cyl,head,sect"	: disk drive is present, with specified geometry
+ "hdx=autotune"		: driver will attempt to tune interface speed
+				to the fastest PIO mode supported,
+				if possible for this drive only.
+				Not fully supported by all chipset types,
+				and quite likely to cause trouble with
+				older/odd IDE drives.
+ "hdx=slow"		: insert a huge pause after each access to the data
+				port. Should be used only as a last resort.
+
+ "idebus=xx"		: inform IDE driver of VESA/PCI bus speed in MHz,
+				where "xx" is between 20 and 66 inclusive,
+				used when tuning chipset PIO modes.
+				For PCI bus, 25 is correct for a P75 system,
+				30 is correct for P90,P120,P180 systems,
+				and 33 is used for P100,P133,P166 systems.
+				If in doubt, use idebus=33 for PCI.
+				As for VLB, it is safest to not specify it.
+				Bigger values are safer than smaller ones.
+
+ "idex=noprobe"		: do not attempt to access/use this interface
+ "idex=base"		: probe for an interface at the addr specified,
+				where "base" is usually 0x1f0 or 0x170
+				and "ctl" is assumed to be "base"+0x206
+ "idex=base,ctl"	: specify both base and ctl
+ "idex=base,ctl,irq"	: specify base, ctl, and irq number
+ "idex=autotune"	: driver will attempt to tune interface speed
+				to the fastest PIO mode supported,
+				for all drives on this interface.
+				Not fully supported by all chipset types,
+				and quite likely to cause trouble with
+				older/odd IDE drives.
+ "idex=noautotune"	: driver will NOT attempt to tune interface speed
+				This is the default for most chipsets,
+				except the cmd640.
+ "idex=serialize"	: do not overlap operations on idex and ide(x^1)
+
+ The following are valid ONLY on ide0,
+ and the defaults for the base,ctl ports must not be altered.
+
+ "ide0=dtc2278"		: probe/support DTC2278 interface
+ "ide0=ht6560b"		: probe/support HT6560B interface
+ "ide0=cmd640_vlb"	: *REQUIRED* for VLB cards with the CMD640 chip
+			  (not for PCI -- automatically detected)
+ "ide0=qd6580"		: probe/support qd6580 interface
+ "ide0=ali14xx"		: probe/support ali14xx chipsets (ALI M1439/M1445)
+ "ide0=umc8672"		: probe/support umc8672 chipsets
+
+Everything else is rejected with a "BAD OPTION" message.
+
+================================================================================
+
+Some Terminology
+----------------
+IDE = Integrated Drive Electronics, meaning that each drive has a built-in
+controller, which is why an "IDE interface card" is not a "controller card".
+
+IDE drives are designed to attach almost directly to the ISA bus of an AT-style
+computer.  The typical IDE interface card merely provides I/O port address
+decoding and tri-state buffers, although several newer localbus cards go much
+beyond the basics.  When purchasing a localbus IDE interface, avoid cards with
+an onboard BIOS and those which require special drivers.  Instead, look for a
+card which uses hardware switches/jumpers to select the interface timing speed,
+to allow much faster data transfers than the original 8MHz ISA bus allows.
+
+ATA = AT (the old IBM 286 computer) Attachment Interface, a draft American
+National Standard for connecting hard drives to PCs.  This is the official
+name for "IDE".
+
+The latest standards define some enhancements, known as the ATA-2 spec,
+which grew out of vendor-specific "Enhanced IDE" (EIDE) implementations.
+
+ATAPI = ATA Packet Interface, a new protocol for controlling the drives,
+similar to SCSI protocols, created at the same time as the ATA2 standard.
+ATAPI is currently used for controlling CDROM and TAPE devices, and will
+likely also soon be used for Floppy drives, removable R/W cartridges,
+and for high capacity hard disk drives.
+
+How To Use *Big* ATA/IDE drives with Linux
+------------------------------------------
+The ATA Interface spec for IDE disk drives allows a total of 28 bits
+(8 bits for sector, 16 bits for cylinder, and 4 bits for head) for addressing
+individual disk sectors of 512 bytes each (in "Linear Block Address" (LBA)
+mode, there is still only a total of 28 bits available in the hardware).
+This "limits" the capacity of an IDE drive to no more than 128GB (Giga-bytes).
+All current day IDE drives are somewhat smaller than this upper limit, and
+within a few years, ATAPI disk drives will raise the limit considerably.
+
+All IDE disk drives "suffer" from a "16-heads" limitation:  the hardware has
+only a four bit field for head selection, restricting the number of "physical"
+heads to 16 or less.  Since the BIOS usually has a 63 sectors/track limit,
+this means that all IDE drivers larger than 504MB (528Meg) must use a "physical"
+geometry with more than 1024 cylinders.
+
+   (1024cyls * 16heads * 63sects * 512bytes/sector) / (1024 * 1024) == 504MB
+
+(Some BIOSs (and controllers with onboard BIOS) pretend to allow "32" or "64"
+ heads per drive (discussed below), but can only do so by playing games with
+ the real (hidden) geometry, which is always limited to 16 or fewer heads).
+
+This presents two problems to most systems:
+
+	1. The INT13 interface to the BIOS only allows 10-bits for cylinder
+	addresses, giving a limit of 1024cyls for programs which use it.
+
+	2. The physical geometry fields of the disk partition table only
+	allow 10-bits for cylinder addresses, giving a similar limit of 1024
+	cyls for operating systems that do not use the "sector count" fields
+	instead of the physical Cyl/Head/Sect (CHS) geometry fields.
+
+Neither of these limitations affects Linux itself, as it (1) does not use the
+BIOS for disk access, and it (2) is clever enough to use the "sector count"
+fields of the partition table instead of the physical CHS geometry fields.
+
+	a) Most folks use LILO to load linux.  LILO uses the INT13 interface
+	to the BIOS to load the kernel at boot time.  Therefore, LILO can only
+	load linux if the files it needs (usually just the kernel images) are
+	located below the magic 1024 cylinder "boundary" (more on this later).
+
+	b) Many folks also like to have bootable DOS partitions on their
+	drive(s).  DOS also uses the INT13 interface to the BIOS, not only
+	for booting, but also for operation after booting.  Therefore, DOS
+	can normally only access partitions which are contained entirely below
+	the magic 1024 cylinder "boundary".
+
+There are at least seven commonly used schemes for kludging DOS to work
+around this "limitation".  In the long term, the problem is being solved
+by introduction of an alternative BIOS interface that does not have the
+same limitations as the INT13 interface.  New versions of DOS are expected
+to detect and use this interface in systems whose BIOS provides it.
+
+But in the present day, alternative solutions are necessary.
+
+The most popular solution in newer systems is to have the BIOS shift bits
+between the cylinder and head number fields.  This is activated by entering
+a translated logical geometry into the BIOS/CMOS setup for the drive.
+Thus, if the drive has a geometry of 2100/16/63 (CHS), then the BIOS could
+present a "logical" geometry of 525/64/63 by "shifting" two bits from the
+cylinder number into the head number field for purposes of the partition table,
+CMOS setup, and INT13 interfaces.  Linux kernels 1.1.39 and higher detect and
+"handle" this translation automatically, making this a rather painless solution
+for the 1024 cyls problem.  If for some reason Linux gets confused (unlikely),
+then use the kernel command line parameters to pass the *logical* geometry,
+as in:  hda=525,64,63
+
+If the BIOS does not support this form of drive translation, then several
+options remain, listed below in order of popularity:
+
+	- use a partition below the 1024 cyl boundary to hold the linux
+	boot files (kernel images and /boot directory), and place the rest
+	of linux anywhere else on the drive.  These files can reside in a DOS
+	partition, or in a tailor-made linux boot partition.
+	- use DiskManager software from OnTrack, supplied free with
+	many new hard drive purchases.
+	- use EZ-Drive software (similar to DiskManager).  Note though,
+	that LILO must *not* use the MBR when EZ-Drive is present.
+	Instead, install LILO on the first sector of your linux partition,
+	and mark it as "active" or "bootable" with fdisk.
+	- boot from a floppy disk instead of the hard drive (takes 10 seconds).
+
+If you cannot use drive translation, *and* your BIOS also restricts you to
+entering no more than 1024 cylinders in the geometry field in the CMOS setup,
+then just set it to 1024.  As of v3.5 of this driver, Linux automatically
+determines the *real* number of cylinders for fdisk to use, allowing easy
+access to the full disk capacity without having to fiddle around.
+
+Regardless of what you do, all DOS partitions *must* be contained entirely
+within the first 1024 logical cylinders.  For a 1Gig WD disk drive, here's
+a good "half and half" partitioning scheme to start with:
+
+	geometry = 2100/16/63
+	/dev/hda1 from cyl    1 to  992		dos
+	/dev/hda2 from cyl  993 to 1023		swap
+	/dev/hda3 from cyl 1024 to 2100		linux
+
+To ensure that LILO can boot linux, the boot files (kernel and /boot/*)
+must reside within the first 1024 cylinders of the drive.  If your linux
+root partition is *not* completely within the first 1024 cyls (quite common),
+then you can use LILO to boot linux from files on your DOS partition
+by doing the following after installing slackware (or whatever):
+
+	0. Boot from the "boot floppy" created during the installation
+        1. Mount your DOS partition as /dos (and stick it in /etc/fstab)
+        2. Move your kernel (/vmlinuz) to /dos/vmlinuz with:  mv /vmlinuz /dos
+        3. Edit /etc/lilo.conf to change /vmlinuz to /dos/vmlinuz
+        4. Move /boot to /dos/boot with:  cp -a /boot /dos ; rm -r /boot
+        5. Create a symlink for LILO to use with:  ln -s /dos/boot /boot
+        6. Re-run LILO with:  lilo
+
+	A danger with this approach is that whenever an MS-DOS "defragmentation"
+	program is run (like Norton "speeddisk"), it may move the Linux boot
+	files around, confusing LILO and making the (Linux) system unbootable.
+	Be sure to keep a kernel "boot floppy" at hand for such circumstances.
+	A possible workaround is to mark the Linux files as S+H+R (System,
+	Hidden, Readonly), to prevent most defragmentation programs from
+	moving the files around.
+
+If you "don't do DOS", then partition as you please, but remember to create
+a small partition to hold the /boot directory (and vmlinuz) as described above
+such that they stay within the first 1024 cylinders.
+
+Note that when creating partitions that span beyond cylinder 1024,
+Linux fdisk will complain about "Partition X has different physical/logical
+endings" and emit messages such as "This is larger than 1024, and may cause
+problems with some software".   Ignore this for linux partitions.  The "some
+software" refers to DOS, the BIOS, and LILO, as described previously.
+
+Western Digital ships a "DiskManager 6.03" diskette with all of their big
+hard drives.  Use BIOS translation instead of this if possible, as it is a
+more generally compatible method of achieving the same results (DOS access
+to the entire disk).  However, if you must use DiskManager, it now works
+with Linux 1.3.x in most cases.  Let me know if you still have trouble.
+
+My recommendations to anyone who asks about NEW systems are:
+
+        - buy a motherboard that uses the Intel Triton chipset -- very common.
+        - use IDE for the first two drives, placing them on separate interfaces.
+	- place the IDE cdrom drive as slave on either interface.
+        - if additional disks are to be connected, consider your needs:
+                - fileserver?  Buy a SC200 SCSI adaptor for the next few drives.
+                - personal system?  Use IDE for the next two drives.
+                - still not enough?  Keep adding SC200 SCSI cards as needed.
+
+Most manufacturers make both IDE and SCSI-2 versions of each of their drives.
+The IDE ones are usually faster and cheaper, due to the higher data transfer
+speed of PIO mode4 (ATA2), 16.6MBytes/sec versus 10Mbytes/sec for SCSI-2.
+
+In particular, I recommend Quantum FireBalls as cheap and exceptionally fast.
+The new WD1.6GB models are also cheap screamers.
+
+For really high end systems, go for fast/wide 7200rpm SCSI.  But it'll cost ya!
+
+mlord@pobox.com
diff --git a/Documentation/initrd.txt b/Documentation/initrd.txt
new file mode 100644
index 000000000..220fcb150
--- /dev/null
+++ b/Documentation/initrd.txt
@@ -0,0 +1,286 @@
+Using the initial RAM disk (initrd)
+===================================
+
+Written 1996 by Werner Almesberger <almesber@lrc.epfl.ch> and
+		Hans Lermen <lermen@elserv.ffm.fgan.de>
+
+
+initrd adds the capability to load a RAM disk by the boot loader. This
+RAM disk can then be mounted as the root file system and programs can be
+run from it. Afterwards, a new root file system can be mounted from a
+different device. The previous root (from initrd) is then either moved
+to the directory /initrd or it is unmounted.
+
+initrd is mainly designed to allow system startup to occur in two phases,
+where the kernel comes up with a minimum set of compiled-in drivers, and
+where additional modules are loaded from initrd.
+
+
+Operation
+---------
+
+When using initrd, the system boots as follows:
+
+  1) the boot loader loads the kernel and the initial RAM disk
+  2) the kernel converts initrd into a "normal" RAM disk and
+     frees the memory used by initrd
+  3) initrd is mounted read-write as root
+  4) /linuxrc is executed (this can be any valid executable, including
+     shell scripts; it is run with uid 0 and can do basically everything
+     init can do)
+  5) when linuxrc terminates, the "real" root file system is mounted
+  6) if a directory /initrd exists, the initrd is moved there
+     otherwise, initrd is unmounted
+  7) the usual boot sequence (e.g. invocation of /sbin/init) is performed
+     on the root file system
+
+Note that moving initrd from / to /initrd does not involve unmounting it.
+It is therefore possible to leave processes running on initrd (or leave
+file systems mounted, but see below) during that procedure. However, if
+/initrd doesn't exist, initrd can only be unmounted if it is not used by
+anything. If it can't be unmounted, it will stay in memory.
+
+Also note that file systems mounted under initrd continue to be accessible,
+but their /proc/mounts entries are not updated. Also, if /initrd doesn't
+exist, initrd can't be unmounted and will "disappear" and take those file
+systems with it, thereby preventing them from being re-mounted. It is
+therefore strongly suggested to generally unmount all file systems (except
+of course for the root file system, but including /proc) before switching
+from initrd to the "normal" root file system.
+
+In order to deallocate the memory used for the initial RAM disk, you have
+to execute freeramdisk (see 'Resources' below) after unmounting /initrd.
+
+
+Boot command-line options
+-------------------------
+
+initrd adds the following new options:
+
+  initrd=<path>    (LOADLIN only)
+
+    Loads the specified file as the initial RAM disk. When using LILO, you
+    have to specify the RAM disk image file in /etc/lilo.conf, using the
+    INITRD configuration variable.
+
+  noinitrd
+
+    initrd data is preserved but it is not converted to a RAM disk and
+    the "normal" root file system is mounted. initrd data can be read
+    from /dev/initrd. Note that the data in initrd can have any structure
+    in this case and doesn't necessarily have to be a file system image.
+    This option is used mainly for debugging.
+
+    Note that /dev/initrd is read-only and that it can only be used once.
+    As soon as the last process has closed it, all data is freed and
+    /dev/initrd can't be opened any longer.
+
+  root=/dev/ram
+
+    initrd is mounted as root, and /linuxrc is started. If no /linuxrc
+    exists, the normal boot procedure is followed, with the RAM disk
+    still mounted as root. This option is mainly useful when booting from
+    a floppy disk. Compared to directly mounting an on-disk file system,
+    the intermediate step of going via initrd adds a little speed
+    advantage and it allows the use of a compressed file system.
+    Also, together with LOADLIN you may load the RAM disk directly from
+    CDrom or disk, hence having a floppyless boot from CD,
+    e.g.: E:\loadlin E:\bzImage root=/dev/ram initrd=E:\rdimage
+
+
+Installation
+------------
+
+First, the "normal" root file system has to be prepared as follows:
+
+# mknod /dev/initrd b 0 250 
+# chmod 400 /dev/initrd
+# mkdir /initrd
+
+If the root file system is created during the boot procedure (i.e. if
+you're creating an install floppy), the root file system creation
+procedure should perform these operations.
+
+Note that neither /dev/initrd nor /initrd are strictly required for
+correct operation of initrd, but it is a lot easier to experiment with
+initrd if you have them, and you may also want to use /initrd to pass
+data to the "real" system.
+
+Second, the kernel has to be compiled with RAM disk support and with
+support for the initial RAM disk enabled. Also, at least all components
+needed to execute programs from initrd (e.g. executable format and file
+system) must be compiled into the kernel.
+
+Third, you have to create the RAM disk image. This is done by creating a
+file system on a block device and then by copying files to it as needed.
+With recent kernels, at least three types of devices are suitable for
+that:
+
+ - a floppy disk (works everywhere but it's painfully slow)
+ - a RAM disk (fast, but allocates physical memory)
+ - a loopback device (the most elegant solution, but currently requires a
+   modified mount)
+
+We'll describe the RAM disk method:
+
+ 1) make sure you have a RAM disk device /dev/ram (block, major 1, minor 0)
+ 2) create an empty file system of the appropriate size, e.g.
+    # mke2fs -m0 /dev/ram 300   
+    (if space is critical, you may want to use the Minix FS instead of Ext2)
+ 3) mount the file system on an appropriate directory, e.g.
+    # mount -t ext2 /dev/ram /mnt
+ 4) create the console device:
+    # mkdir /mnt/dev
+    # mknod /mnt/dev/tty1 c 4 1
+ 5) copy all the files that are needed to properly use the initrd
+    environment. Don't forget the most important file, /linuxrc
+    Note that /linuxrc's permissions must include "x" (execute).
+ 6) unmount the RAM disk
+    # umount /dev/ram
+ 7) copy the image to a file
+    # dd if=/dev/ram bs=1k count=300 of=/boot/initrd
+ 8) deallocate the RAM disk
+    # freeramdisk /dev/ram
+
+For experimenting with initrd, you may want to take a rescue floppy (e.g.
+rescue.gz from Slackware) and only add a symbolic link from /linuxrc to
+/bin/sh, e.g.
+
+ # gunzip <rescue.gz >/dev/ram
+ # mount -t minix /dev/ram /mnt
+ # ln -s /bin/sh /mnt/linuxrc
+ # umount /dev/ram
+ # dd if=/dev/ram bs=1k count=1440 of=/boot/initrd
+ # freeramdisk /dev/ram
+
+Finally, you have to boot the kernel and load initrd. Currently,
+preliminary versions of LOADLIN 1.6 and LILO 18 support initrd (see
+below for where to get them). With LOADLIN, you simply execute
+
+     LOADLIN <kernel> initrd=<disk_image>
+e.g. LOADLIN C:\LINUX\VMLINUZ initrd=C:\LINUX\INITRD
+
+With LILO, you add the option INITRD=<path> to either the global section
+or to the section of the respective kernel in /etc/lilo.conf, e.g.
+
+  image = /vmlinuz
+    initrd = /boot/initrd
+
+and run /sbin/lilo
+
+Now you can boot and enjoy using initrd.
+
+
+Setting the root device
+-----------------------
+
+By default, the standard settings in the kernel are used for the root
+device, i.e. the default compiled in or set with rdev, or what was passed
+with root=xxx on the command line, or, with LILO, what was specified in
+/etc/lilo.conf It is also possible to use initrd with an NFS-mounted
+root; you have to use the nfs_root_name and nfs_root_addrs boot options
+for this.
+
+It is also possible to change the root device from within the initrd
+environment. In order to do so, /proc has to be mounted. Then, the
+following files are available:
+
+  /proc/sys/kernel/real-root-dev
+  /proc/sys/kernel/nfs-root-name
+  /proc/sys/kernel/nfs-root-addrs
+
+real-root-dev can be changed by writing the number of the new root FS
+device to it, e.g.
+
+  # echo 0x301 >/proc/sys/kernel/real-root-dev
+
+for /dev/hda1. When using an NFS-mounted root, nfs-root-name and
+nfs-root-addrs have to be set accordingly and then real-root-dev has to
+be set to 0xff, e.g.
+
+  # echo /var/nfsroot >/proc/sys/kernel/nfs-root-name
+  # echo 193.8.232.2:193.8.232.7::255.255.255.0:idefix \
+    >/proc/sys/kernel/nfs-root-addrs
+  # echo 255 >/proc/sys/kernel/real-root-dev
+
+If the root device is set to the RAM disk, the root file system is not
+moved to /initrd, but the boot procedure is simply continued by starting
+init on the initial RAM disk.
+
+
+Usage scenarios
+---------------
+
+The main motivation for implementing initrd was to allow for modular
+kernel configuration at system installation. The procedure would work
+as follows:
+
+  1) systems boots from floppy or other media with a minimal kernel
+     (e.g. support for RAM disks, initrd, a.out, and the ext2 FS) and
+     loads initrd
+  2) /linuxrc determines what is needed to (1) mount the "real" root FS
+     (i.e. device type, device drivers, file system) and (2) the
+     distribution media (e.g. CD-ROM, network, tape, ...). This can be
+     done by asking the user, by auto-probing, or by using a hybrid
+     approach.
+  3) /linuxrc loads the necessary modules
+  4) /linuxrc creates and populates the root file system (this doesn't
+     have to be a very usable system yet)
+  5) /linuxrc unmounts the root file system and possibly any other file
+     systems it has mounted, sets /proc/sys/kernel/..., and terminates
+  6) the root file system is mounted
+  7) now that we're sure that the file system is accessible and intact,
+     the boot loader can be installed
+  8) the boot loader is configured to load an initrd with the set of
+     modules that was used to bring up the system (e.g. /initrd can be
+     modified, then unmounted, and finally, the image is written from
+     /dev/ram to a file)
+  9) now the system is bootable and additional installation tasks can be
+     performed
+
+The key role of initrd here is to re-use the configuration data during
+normal system operation without requiring the use of a bloated "generic"
+kernel or re-compilation or re-linking of the kernel.
+
+A second scenario is for installations where Linux runs on systems with
+different hardware configurations in a single administrative domain. In
+such cases, it is desirable to generate only a small set of kernels
+(ideally only one) and to keep the system-specific part of configuration
+information as small as possible. In this case, a common initrd could be
+generated with all the necessary modules. Then, only /linuxrc or a file
+read by it would have to be different.
+
+A third scenario are more convenient recovery disks, because information
+like the location of the root FS partition doesn't have to be provided at
+boot time, but the system loaded from initrd can use a user-friendly
+dialog and it can also perform some sanity checks (or even some form of
+auto-detection).
+
+Last not least, CDrom distributors may use it for better installation from CD,
+either using a LILO boot floppy and bootstrapping a bigger ramdisk via
+initrd from CD, or using LOADLIN to directly load the ramdisk from CD
+without need of floppies.
+
+Since initrd is a fairly generic mechanism, it is likely that additional
+uses will be found.
+
+
+Resources
+---------
+
+The bzImage+initrd patch (bzImage is an extension to load kernels directly
+above 1 MB, which allows kernels sizes of up to approximately 2 MB) can be
+found at
+ftp://lrcftp.epfl.ch/pub/people/almesber/lilo/bzImage+initrd-1.3.71.patch.gz
+and
+ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/bzImage+initrd-1.3.71.patch.gz
+
+A preliminary version of LOADLIN 1.6 is available on
+ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/loadlin-1.6-pre8-bin.tgz
+
+A preliminary version of LILO 18 is available on
+ftp://lrcftp.epfl.ch/pub/people/almesber/lilo/lilo.18dev3.tar.gz
+
+A very simple example for building an image for initrd, also including
+the program 'freeramdisk', can be found on
+ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/initrd-example.tgz
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
new file mode 100644
index 000000000..73ba54c38
--- /dev/null
+++ b/Documentation/ioctl-number.txt
@@ -0,0 +1,108 @@
+Ioctl Numbers
+5 Oct 1996
+Michael Chastain
+<mec@duracef.shout.net>
+
+If you are adding new ioctl's to the kernel, you should use the _IO
+macros defined in <linux/ioctl.h>:
+
+    _IO    an ioctl with no parameters
+    _IOW   an ioctl with write parameters (from user's point of view)
+    _IOR   an ioctl with read parameters (from user's point of view)
+    _IOWR  an ioctl with both write and read parameters.
+
+'Write' and 'read' are from the user's point of view.  This is like the
+system calls 'write' and 'read'.  For example, a SET_FOO ioctl would be
+_IOW, although the kernel would actually read data from user space; a
+GET_FOO ioctl would be _IOR, although the kernel would actually write
+data to user space.
+
+The first argument to _IO, _IOW, _IOR, or _IOWR is an identifying letter
+or number from the table below.  If you are writing a driver for a new
+device and need a letter, pick an unused letter.  You can register the
+letter by patching this file and submitting the patch to Linus Torvalds.
+Or you can e-mail me at <mec@duracef.shout.net> and I'll register one
+for you.
+
+The second argument to _IO, _IOW, _IOR, or _IOWR is a sequence number
+to distinguish ioctls from each other.  The third argument is the size
+of the structure going into the kernel or coming out of the kernel.
+
+Some devices use their major number as the identifier; this is not
+recommended.  Some devices are even more irregular and don't follow
+the convention at all.
+
+Following the convention is good because:
+
+(1) Keeping the ioctl's globally unique helps error checking:
+    if a program calls an ioctl on the wrong device, it will get an
+    error rather than some unexpected behaviour.
+
+(2) The 'strace' build procedure automatically finds ioctl numbers
+    defined with _IO, _IOW, _IOR, or _IOWR.
+
+(3) 'strace' can decode numbers back into useful names when the
+    numbers are unique.
+
+(4) People looking for ioctls can grep for them more easily when
+    the convention is used to define the ioctl numbers.
+
+(5) When following the convention, the driver code can use generic
+    code to call verify_area to validate parameters.
+
+This table lists ioctls visible from user land for Linux/i386.  It is
+current to Linux 2.1.1
+
+Code	Seq#	Include File		Comments
+========================================================
+0x00	01-02	linux/fs.h		conflict!
+0x00	01-04	scsi/scsi_ioctl.h	conflict!
+0x02	all	linux/fd.h
+0x03	all	linux/hdreg.h
+0x04	all	linux/umsdos_fs.h
+0x06	all	linux/lp.h
+0x09	all	linux/md.h
+0x12	all	linux/fs.h
+0x20	all	linux/cm206.h
+0x22	all	linux/scc.h		conflict! (version 2.01 of z8530drv)
+0x22	all	scsi/sg.h		conflict!
+'A'	all	linux/apm_bios.h
+'B'	all	linux/baycom.h
+'C'	all	linux/soundcard.h
+'F'	all	linux/fb.h
+'I'	all	linux/isdn.h
+'K'	all	linux/kd.h
+'L'	all	linux/loop.h
+'M'	all	linux/soundcard.h
+'P'	all	linux/soundcard.h
+'Q'	all	linux/soundcard.h
+'R'	all	linux/random.h
+'S'	00-1F	linux/cdrom.h
+'S'	20-7F	linux/ucdrom.h
+'S'	80-81	scsi/scsi_ioctl.h
+'S'	82-FF	scsi/scsi.h
+'T'	all	linux/soundcard.h	conflict!
+'T'	all	asm-i386/ioctls.h	conflict!
+'V'	all	linux/vt.h
+'W'	00-1F	linux/pcwd.h
+'Y'	all	linux/cyclades.h
+'Z'	all	linux/scc.h		version 2.2 of z8530drv
+'a'	all	various, see http://lrcwww.epfl.ch/linux-atm/magic.html
+'c'	all	linux/comstats.h
+'f'	all	linux/ext2_fs.h
+'m'	all	linux/mtio.h		conflict!
+'m'	all	linux/soundcard.h	conflict!
+'n'	all	linux/ncp_fs.h
+'p'	all	linux/mc146818rtc.h
+'r'	all	linux/msdos_fs.h
+'s'	all	linux/cdk.h
+'t'	00-7F	linux/if_ppp.h
+'t'	80-8F	linux/isdn_ppp.h
+'u'	all	linux/smb_fs.h
+'v'	all	linux/ext2_fs.h
+'w'	all	CERN SCI driver (in development)
+0x89	00-0F	asm-i386/sockios.h
+0x89	10-FF	linux/sockios.h
+0x90	00	linux/sbpcd.h
+0x99	00-0F	537-Addinboard driver (in development, e-mail contact:
+					b.kohl@ipn-b.comlink.apc.org)
diff --git a/Documentation/isdn/00-INDEX b/Documentation/isdn/00-INDEX
new file mode 100644
index 000000000..b707c346d
--- /dev/null
+++ b/Documentation/isdn/00-INDEX
@@ -0,0 +1,21 @@
+00-INDEX
+	- this file (info on ISDN implementation for Linux)
+CREDITS
+	- list of the kind folks that brought you this stuff.
+INTERFACE
+	- description of Linklevel and Hardwarelevel ISDN interface.
+README
+	- general info on what you need and what to do for Linux ISDN.
+README.audio
+	- info for running audio over ISDN.
+README.icn
+	- info on the ICN-ISDN-card and its driver.
+README.pcbit
+	- info on the PCBIT-D ISDN adapter and driver.
+README.syncppp
+	- info on running Sync PPP over ISDN.
+README.teles
+	- info on driver for Teles compatible ISDN cards.
+syncPPP.FAQ
+	- frequently asked questions about running PPP over ISDN.
+
diff --git a/Documentation/isdn/CREDITS b/Documentation/isdn/CREDITS
new file mode 100644
index 000000000..6c546c4e1
--- /dev/null
+++ b/Documentation/isdn/CREDITS
@@ -0,0 +1,45 @@
+
+I want to thank all who contributed to this project and especially to:
+(in alphabetical order)
+
+Thomas Bogendörfer (tsbogend@bigbug.franken.de)
+  Tester, lots of bugfixes and hints.
+
+Alan Cox (alan@cymru.net)
+  For help getting into standard-kernel.
+
+Volker Götz (volker@oops.franken.de)
+  For contribution of man-pages, the imontty-tool and a perfect
+  maintaining of the mailing-list at hub-wue.
+
+Michael Hipp (Michael.Hipp@student.uni-tuebingen.de)
+  For his Sync-PPP-code.
+
+Karsten Keil (isdn4@temic-ech.spacenet.de)
+  For adding 1TR6-support to the Teles-driver.
+
+Michael Knigge (knick@cove.han.de)
+  For contributing the imon-tool
+
+Andreas Kool (akool@Kool.f.EUnet.de)
+  For contribution of the isdnlog/isdnrep-tool
+
+Pedro Roque Marques (roque@di.fc.ul.pt)
+  For lot of new ideas and the pcbit driver.
+
+Eberhard Moenkeberg (emoenke@gwdg.de)
+  For testing and help to get into kernel.
+
+Jan den Ouden (denouden@groovin.xs4all.nl)
+  For contribution of the teles-driver
+
+Max Riegel (riegel@max.franken.de)
+  For making the ICN hardware-documentation and test-equipment available.
+
+Gerhard 'Fido' Schneider (fido@wuff.franken.de)
+  For heavy-duty-beta-testing with his BBS ;)
+
+Thomas Uhl (uhl@hn-net.de)
+  For distributing the cards.
+  For pushing me to work ;-)
+
diff --git a/Documentation/isdn/INTERFACE b/Documentation/isdn/INTERFACE
new file mode 100644
index 000000000..6ba401123
--- /dev/null
+++ b/Documentation/isdn/INTERFACE
@@ -0,0 +1,644 @@
+$Id: INTERFACE,v 1.3 1996/06/25 17:52:41 fritz Exp $
+
+Description of the Interface between Linklevel and Hardwarelevel
+  of isdn4linux:
+
+
+  The Communication between Linklevel (LL) and Hardwarelevel (HL)
+  is based on the struct isdn_if (defined in isdnif.h).
+
+  An HL-driver can register itself at LL by calling the function
+  register_isdn() with a pointer to that struct. Prior to that, it has
+  to preset some of the fields of isdn_if. The LL sets the rest of
+  the fields. All further communication is done via callbacks using
+  the function-pointers defined in isdn_if.
+
+  Changes/Version numbering:
+
+  During development of the ISDN subsystem, several changes have been
+  made to the interface. Before it went into kernel, the package
+  had a unique version number. The last version, distributed separately
+  was 0.7.4. When the subsystem went into kernel, every functional unit
+  got a separate version number. These numbers are shown at initialization,
+  separated by slashes:
+
+     c.c/t.t/n.n/p.p/a.a
+
+  where
+
+   c.c is the revision of the common code.
+   t.t is the revision of the tty related code.
+   n.n is the revision of the network related code.
+   p.p is the revision of the ppp related code.
+   a.a is the revision of the audio related code.
+
+  Changes in this document are marked with '***CHANGEx' where x representing
+  the version number. If that number starts with 0, it refers to the old,
+  separately distributed package. If it starts with one of the letters
+  above, it refers to the revision of the corresponding module. 
+
+1. Description of the fields of isdn_if:
+
+  int channels;
+
+    This field has to be set by the HL-driver to the number of channels
+    supported prior to calling register_isdn(). Upon return of the call,
+    the LL puts an id there, which has to be used by the HL-driver when
+    invoking the other callbacks.
+
+  int maxbufsize;
+
+    ***CHANGE0.6: New since this version.
+
+    Also to be preset by the HL-driver. With this value the HL-driver
+    tells to the LL the maximum size of a data-packet it will accept. 
+
+  unsigned long features;
+
+    To be preset by the HL-driver. Using this field, the HL-driver
+    announces the features supported. At the moment this is limited to
+    report the supported layer2 and layer3-protocols. For setting this
+    field the constants ISDN_FEATURE..., declared in isdnif.h have to be
+    used.
+
+    ***CHANGE0.7.1: The line type (1TR6, EDSS1) has to be set.
+
+  unsigned short hl_hdrlen;
+
+    ***CHANGED.7.4: New field.
+
+    To be preset by the HL-driver, if it supports sk_buff's. The driver
+    should put here the amount of additional space needed in sk-buff's for
+    its internal purposes. Drivers not supporting sk_buff's should put
+    initialize this field to 0.
+
+  void (*rcvcallb)(int, int, u_char*, int);
+
+    ***CHANGEc1.14: Declared obsolete. Do NOT use this field/function
+                    anymore, since it will be removed when all current
+                    LL drivers have been changed accordingly. Use
+                    rcvcallb_skb instead.
+
+    This field will be set by LL. The HL-driver delivers received data-
+    packets by calling this function.
+
+    Parameter:
+      int    driver-Id
+      int    Channel-number locally to the driver. (starting with 0)
+      u_char Pointer to received data. (in kernel-space)
+      int    length of data-packet.
+
+  void (*rcvcallb_skb)(int, int, struct sk_buff *)
+
+    ***CHANGED.7.4: New field.
+
+    This field will be set by LL. The HL-driver delivers received data-
+    packets by calling this function. Upon calling, the HL-driver must
+    already have its private data pulled off the head of the sk_buff.
+
+    Parameter:
+      int              driver-Id
+      int              Channel-number locally to the driver. (starting with 0)
+      struct sk_buff * Pointer to sk_buff, containing received data.
+
+  int (*statcallb)(isdn_ctrl*);
+
+    This field will be set by LL. This function has to be called by the
+    HL-driver for signaling status-changes or other events to the LL.
+
+    Parameter:
+      isdn_ctrl*
+
+      The struct isdn_ctrl also defined in isdn_if. The exact meanings of its
+      fields are described together with the descriptions of the possible
+      events. Here is only a short description of the fields:
+
+        driver  = driver Id.
+        command = event-type. (one of the constants ISDN_STAT_...)
+        arg     = depends on event-type.
+        num     = depends on event-type.
+
+    Returnvalue:
+      0 on success, else -1
+
+  int (*command)(isdn_ctrl*);
+
+    This field has to be preset by the HL-driver. It points to a function,
+    to be called by LL to perform functions like dialing, B-channel
+    setup, etc. The exact meaning of the parameters is described with the
+    descriptions of the possible commands.
+
+    Parameter:
+      isdn_ctrl*
+        driver  = driver-Id
+        command = command to perform. (one of the constants ISDN_CMD_...)
+        arg     = depends on command.
+        num     = depends on command.
+    
+    Returnvalue:
+      >=0 on success, else error-code (-ENODEV etc.)
+
+  int (*writebuf)(int, int, u_char*, int, int);
+
+    ***CHANGEc1.14: Declared obsolete. Do NOT use this field/function
+                    anymore, since it will be removed when all current
+                    LL drivers have been changed accordingly. Set this
+                    field to NULL and use writebuf_skb instead.
+
+    This field has to be preset by the HL-driver. The given function will
+    be called by the LL for delivering data to be send via B-Channel.
+
+    Parameter:
+      int     driver-Id ***CHANGE.7.4: New parameter.
+      int     channel-number locally to the HL-driver. (starts with 0)
+      u_char* pointer to data.
+      int     length of data-packet.
+      int     flag: 0 = call from within kernel-space. (HL-driver must use
+                        memcpy, may NOT use schedule())
+                    1 = call from user-space. (HL-driver must use
+                        memcpy_fromfs, use of schedule() allowed)
+
+    Returnvalue:
+      Length of data accepted on success, else error-code (-EINVAL on
+      oversized packets etc.)
+
+  int (*writebuf_skb)(int, int, struct sk_buff *)
+
+    ***CHANGED.7.4: New field.
+
+    This field has to be preset by the HL-driver. The given function will
+    be called by the LL for delivering data to be send via B-Channel.
+
+ 
+    Parameter:
+      int              driver-Id ***CHANGE.7.4: New parameter.
+      int              channel-number locally to the HL-driver. (starts with 0)
+      struct sk_buff * Pointer to sk_buff containing data to be send via
+                       B-channel.
+
+    Returnvalue:
+      Length of data accepted on success, else error-code (-EINVAL on
+      oversized packets etc.)
+
+  int (*writecmd)(u_char*, int, int, int, int);
+
+    This field has to be preset by the HL-driver. The given function will be
+    called to perform write-requests on /dev/isdnctrl (i.e. sending commands
+    to the card) The data-format is hardware-specific. This function is
+    intended for debugging only. It is not necessary for normal operation
+    and never will be called by the tty-emulation- or network-code. If
+    this function is not supported, the driver has to set NULL here.
+
+    Parameter:
+      u_char* pointer to data.
+      int     length of data.
+      int     flag: 0 = call from within kernel-space. (HL-driver must use
+                        memcpy, may NOT use schedule())
+                    1 = call from user-space. (HL-driver must use
+                        memcpy_fromfs, use of schedule() allowed)
+      int     driver-Id.
+      int     channel-number locally to the HL-driver. (starts with 0)
+
+***CHANGEc1.14: The driver-Id and channel-number are new since this revision.
+
+    Returnvalue:
+      Length of data accepted on success, else error-code (-EINVAL etc.)
+
+  int (*readstat)(u_char*, int, int, int, int);
+
+    This field has to be preset by the HL-driver. The given function will be
+    called to perform read-requests on /dev/isdnctrl (i.e. reading replies
+    from the card) The data-format is hardware-specific. This function is
+    intended for debugging only. It is not necessary for normal operation
+    and never will be called by the tty-emulation- or network-code. If
+    this function is not supported, the driver has to set NULL here.
+
+    Parameter:
+      u_char* pointer to data.
+      int     length of data.
+      int     flag: 0 = call from within kernel-space. (HL-driver must use
+                        memcpy, may NOT use schedule())
+                    1 = call from user-space. (HL-driver must use
+                        memcpy_fromfs, use of schedule() allowed)
+      int     driver-Id.
+      int     channel-number locally to the HL-driver. (starts with 0)
+
+***CHANGEc1.14: The driver-Id and channel-number are new since this revision.
+
+    Returnvalue:
+      Length of data on success, else error-code (-EINVAL etc.)
+
+  char id[20];
+       ***CHANGE0.7: New since this version.
+
+   This string has to be preset by the HL-driver. Its purpose is for
+   identification of the driver by the user. Eg.: it is shown in the
+   status-info of /dev/isdninfo. Furthermore it is used as Id for binding
+   net-interfaces to a specific channel. If a string of length zero is
+   given, upon return, isdn4linux will replace it by a generic name. (line0,
+   line1 etc.) It is recommended to make this string configurable during
+   module-load-time. (copy a global variable to this string.) For doing that,
+   modules 1.2.8 or newer are necessary.
+
+2. Description of the commands, a HL-driver has to support:
+
+   All commands will be performed by calling the function command() described
+   above from within the LL. The field command of the struct-parameter will
+   contain the desired command, the field driver always is set to the
+   appropriate driver-Id.
+
+   Until now, the following commands are defined:
+
+
+   ISDN_CMD_IOCTL:
+
+     This command is intended for performing ioctl-calls for configuring
+     hardware or similar purposes (setting port-addresses, loading firmware
+     etc.) For this purpose, in the LL all ioctl-calls with an argument
+     >= IIOCDRVCTL (0x100) will be handed transparently to this
+     function after subtracting 0x100 and placing the result in arg.
+     Example:
+       If a userlevel-program calls ioctl(0x101,...) the function gets
+       called with the field command set to 1.
+
+     Parameter:
+       driver  = driver-Id.
+       command = ISDN_CMD_IOCTL
+       arg     = Original ioctl-cmd - IIOCDRVCTL
+       num     = first bytes filled with (unsigned long)arg
+   
+     Returnvalue:
+       Depending on driver.
+
+  
+  ISDN_CMD_DIAL:
+
+    This command is used to tell the HL-driver it should dial a given
+    number.
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_DIAL
+      arg         = channel-number locally to the driver. (starting with 0)
+      num         = An ASCII-String containing the number to dial, the own
+                    EAZ or MSN, the Service-Indicator and the Additional
+                    Info. Format:
+                    "%s,%s,%d,%d" RemotePhoneNumber,EazOrMsn,SI,AI
+                    If the Line has been designed as SPV (a special german
+                    feature, meaning semi-leased-line) the number has to
+                    start with an "S".
+      ***CHANGE0.6: In previous versions the EAZ has been given in the
+                    highbyte of arg.
+    ***CHANGE0.7.1: New since this version: ServiceIndicator and AddInfo.
+
+  ISDN_CMD_ACCEPTD:
+
+    With this command, the HL-driver is told to accept a D-Channel-setup.
+    (Response to an incoming call)
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_ACCEPTD
+      arg         = channel-number locally to the driver. (starting with 0)
+      num         = unused.
+
+  ISDN_CMD_ACCEPTB:
+
+    With this command, the HL-driver is told to perform a B-Channel-setup.
+    (after establishing D-Channel-Connection)
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_ACCEPTB
+      arg         = channel-number locally to the driver. (starting with 0)
+      num         = unused.
+
+  ISDN_CMD_HANGUP:
+
+    With this command, the HL-driver is told to hangup (B-Channel if
+    established first, then D-Channel). This command is also used for
+    actively rejecting an incoming call.
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_HANGUP
+      arg         = channel-number locally to the driver. (starting with 0)
+      num         = unused.
+
+  ISDN_CMD_CLREAZ:
+
+    With this command, the HL-driver is told not to signal incoming
+    calls to the LL.
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_CLREAZ
+      arg         = channel-number locally to the driver. (starting with 0)
+      num         = unused.
+
+  ISDN_CMD_SETEAZ:
+
+    With this command, the HL-driver is told to signal incoming calls for
+    the given EAZs/MSNs to the LL.
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_SETEAZ
+      arg         = channel-number locally to the driver. (starting with 0)
+      num         = ASCII-String, containing the desired EAZ's/MSN's
+                    (comma-separated). If an empty String is given, the
+                    HL-driver should respond to ALL incoming calls,
+                    regardless of the destination-address.
+      ***CHANGE0.6: New since this version the "empty-string"-feature.
+
+  ISDN_CMD_GETEAZ: (currently unused)
+
+    With this command, the HL-driver is told to report the current setting
+    given with ISDN_CMD_SETEAZ.
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_GETEAZ
+      arg         = channel-number locally to the driver. (starting with 0)
+      num         = ASCII-String, containing the current EAZ's/MSN's
+
+  ISDN_CMD_SETSIL: (currently unused)
+
+    With this command, the HL-driver is told to signal only incoming
+    calls with the given Service-Indicators.
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_SETSIL
+      arg         = channel-number locally to the driver. (starting with 0)
+      num         = ASCII-String, containing the desired Service-Indicators.
+
+  ISDN_CMD_GETSIL: (currently unused)
+
+    With this command, the HL-driver is told to return the current
+    Service-Indicators it will respond to.
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_SETSIL
+      arg         = channel-number locally to the driver. (starting with 0)
+      num         = ASCII-String, containing the current Service-Indicators.
+
+  ISDN_CMD_SETL2:
+
+    With this command, the HL-driver is told to select the given Layer-2-
+    protocol. This command is issued by the LL prior to ISDN_CMD_DIAL or
+    ISDN_CMD_ACCEPTD.
+
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_SETL2
+      arg         = channel-number locally to the driver. (starting with 0)
+                    logical or'ed with (protocol-Id << 8)
+                    protocol-Id is one of the constants ISDN_PROTO_L2...
+      num         = unused.
+
+  ISDN_CMD_GETL2: (currently unused)
+
+    With this command, the HL-driver is told to return the current
+    setting of the Layer-2-protocol.
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_GETL2
+      arg         = channel-number locally to the driver. (starting with 0)
+      num         = unused.
+    Returnvalue:
+      current protocol-Id (one of the constants ISDN_L2_PROTO)
+
+  ISDN_CMD_SETL3:
+
+    With this command, the HL-driver is told to select the given Layer-3-
+    protocol. This command is issued by the LL prior to ISDN_CMD_DIAL or
+    ISDN_CMD_ACCEPTD.
+
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_SETL3
+      arg         = channel-number locally to the driver. (starting with 0)
+                    logical or'ed with (protocol-Id << 8)
+                    protocol-Id is one of the constants ISDN_PROTO_L3...
+      num         = unused.
+
+  ISDN_CMD_GETL2: (currently unused)
+
+    With this command, the HL-driver is told to return the current
+    setting of the Layer-3-protocol.
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_GETL3
+      arg         = channel-number locally to the driver. (starting with 0)
+      num         = unused.
+    Returnvalue:
+      current protocol-Id (one of the constants ISDN_L3_PROTO)
+
+  ISDN_CMD_LOCK:
+
+    With this command the HL-driver is told, that it will be used by the
+    LL and therefore may not be unloaded. The HL-driver should use
+    MOD_INC_USE_COUNT to tell that to the kernel.
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_LOCK
+      arg         = unused.
+      num         = unused.
+
+  ISDN_CMD_UNLOCK:
+
+    With this command the HL-driver is told, that it is no more used by the
+    LL and therefore may be unloaded. The HL-driver should use
+    DEC_INC_USE_COUNT to tell that to the kernel.
+
+    Parameter:
+      driver      = driver-Id.
+      command     = ISDN_CMD_UNLOCK
+      arg         = unused.
+      num         = unused.
+
+3. Description of the events to be signaled by the HL-driver to th LL.
+
+  All status-changes are signaled via calling the previously described
+  function statcallb(). The field command of the struct isdn_cmd has
+  to be set by the HL-driver with the appropriate Status-Id (event-number).
+  The field arg has to be set to the channel-number (locally to the driver,
+  starting with 0) to which this event applies. (Exception: STAVAIL-event)
+
+  Until now, the following Status-Ids are defined:
+
+  ISDN_STAT_AVAIL:
+
+    With this call, the HL-driver signals the availability of new data
+    for readstat(). Used only for debugging-purposes, see description
+    of readstat().
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_STAVAIL
+      arg         = length of available data.
+      num         = unused.
+
+  ISDN_STAT_ICALL:
+
+    With this call, the HL-driver signals an incoming call to the LL.
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_ICALL
+      arg         = channel-number, locally to the driver. (starting with 0)
+      num         = ASCII-String in the following format:
+                    "%s,%d,%d,%s",CallerNumber,ServiceIndicator,AddInfo,
+                    CalledNumber.
+
+  ISDN_STAT_RUN:
+
+    With this call, the HL-driver signals availability of the ISDN-card.
+    (after initializing, loading firmware)
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_RUN
+      arg         = unused.
+      num         = unused.
+
+  ISDN_STAT_STOP:
+
+    With this call, the HL-driver signals unavailability of the ISDN-card.
+    (before unloading, while resetting/reconfiguring the card)
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_STOP
+      arg         = unused.
+      num         = unused.
+
+  ISDN_STAT_DCONN:
+
+   With this call, the HL-driver signals the successful establishment of
+   a D-Channel-connection. (Response to ISDN_CMD_ACCEPTD or ISDN_CMD_DIAL)
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_DCONN
+      arg         = channel-number, locally to the driver. (starting with 0)
+      num         = unused.
+
+  ISDN_STAT_BCONN:
+
+   With this call, the HL-driver signals the successful establishment of
+   a B-Channel-connection. (Response to ISDN_CMD_ACCEPTB or because the
+   remote-station has initiated establishment)
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_BCONN
+      arg         = channel-number, locally to the driver. (starting with 0)
+      num         = unused.
+
+  ISDN_STAT_DHUP:
+
+   With this call, the HL-driver signals the shutdown of a
+   D-Channel-connection. This could be a response to a prior ISDN_CMD_HANGUP,
+   or caused by a remote-hangup or if the remote-station has actively
+   rejected a call.
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_DHUP
+      arg         = channel-number, locally to the driver. (starting with 0)
+      num         = unused.
+
+  ISDN_STAT_BHUP:
+
+   With this call, the HL-driver signals the shutdown of a
+   B-Channel-connection. This could be a response to a prior ISDN_CMD_HANGUP,
+   or caused by a remote-hangup.
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_BHUP
+      arg         = channel-number, locally to the driver. (starting with 0)
+      num         = unused.
+
+  ISDN_STAT_CINF:
+
+   With this call, the HL-driver delivers charge-unit information to the
+   LL.
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_CINF
+      arg         = channel-number, locally to the driver. (starting with 0)
+      num         = ASCII string containing charge-units (digits only).
+
+  ISDN_STAT_LOAD: (currently unused)
+
+  ISDN_STAT_UNLOAD:
+
+   With this call, the HL-driver signals that it will be unloaded now. This
+   tells the LL to release all corresponding data-structures.
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_UNLOAD
+      arg         = unused.
+      num         = unused.
+
+  ISDN_STAT_BSENT:
+
+    With this call the HL-driver signals the delivery of a data-packet.
+    This callback is used by the network-interfaces only, tty-Emulation
+    does not need this call.
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_BSENT
+      arg         = channel-number, locally to the driver. (starting with 0)
+      num         = unused.
+
+  ISDN_STAT_NODCH:
+
+    With this call, the driver has to respond to a prior ISDN_CMD_DIAL, if
+    no D-Channel is available.
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_NODCH
+      arg         = channel-number, locally to the driver. (starting with 0)
+      num         = unused.
+
+  ISDN_STAT_ADDCH: (currently unused)
+
+    This call is planned for HL-drivers, which are unable to check card-type
+    or numbers of supported channels before they have loaded any firmware
+    using ioctl. Those HL-driver simply set the channel-parameter to zero
+    or a minimum channel-number when registering, and later if they know
+    the real amount, perform this call, allocating additional channels.
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_ADDCH
+      arg         = to be defined.
+      num         = to be defined.
+
+  ISDN_STAT_CAUSE:
+
+    With this call, the HL-driver delivers CAUSE-messages to the LL.
+    Currently the LL does not use this messages. Their contents is simply
+    logged via kernel-messages. Therefore, currently the format of the
+    messages is currently completely free. However they should be printable.
+
+    Parameter:
+      driver      = driver-Id
+      command     = ISDN_STAT_NODCH
+      arg         = channel-number, locally to the driver. (starting with 0)
+      num         = ASCII string containing CAUSE-message.
+
diff --git a/Documentation/isdn/README b/Documentation/isdn/README
new file mode 100644
index 000000000..36cc1336f
--- /dev/null
+++ b/Documentation/isdn/README
@@ -0,0 +1,620 @@
+README for the ISDN-subsystem
+
+1. Preface
+
+  1.1 Introduction
+
+  This README describes how to set up and how to use the different parts
+  of the ISDN-subsystem.
+
+  For using the ISDN-subsystem, some additional userlevel programs are
+  necessary. Those programs and some contributed utilities are available
+  at
+
+   ftp.franken.de
+
+   /pub/isdn4linux/isdn4k-utils-<VersionNumber>.tar.gz
+
+
+  We also have set up a mailing-list:
+
+   The isdn4linux-project originates in Germany, and therefore by historical
+   reasons, the mailing-list's primary language is german. However mails
+   written in english have been welcome all the time.
+
+   to subscribe: write a email to majordomo@hub-wue.franken.de,
+   Subject irrelevant, in the message body:
+   subscribe isdn4linux <your_email_address>
+
+   To write to the mailing-list, write to isdn4linux@hub-wue.franken.de
+   
+
+  1.1 Technical details
+
+  In the following Text, the terms MSN and EAZ are used.
+
+  MSN is the abbreviation for (M)ultiple(S)ubscriber(N)umber, and applies
+  to Euro(EDSS1)-type lines. Usually it is simply the phone-number.
+
+  EAZ is the abbreviation of (E)ndgeraete(A)uswahl(Z)iffer and
+  applies to German 1TR6-type lines. This is a one-digit string,
+  simply appended to the base phone-number
+
+  The internal handling is nearly identical, so replace the appropriate
+  term to that one, which applies to your local ISDN-environment.
+
+  When the link-level-module isdn.o is loaded, it supports up to 16
+  low-level-modules with up to 64 channels. (The number 64 is arbitrarily
+  chosen and can be configured at compile-time --ISDN_MAX in isdn.h).
+  A low-level-driver can register itself through an interface (which is
+  defined in isdnif.h) and gets assigned a slot.
+  The following char-devices are made available for each channel:
+  
+  A raw-control-device with the following functions:
+     write: raw D-channel-messages (format: depends on driver).
+     read:  raw D-channel-messages (format: depends on driver).
+     ioctl: depends on driver, for the ICN-driver, the base-address of
+            the ports and the shared memory on the card can be set and read
+            also the boot-code an the protocol software can be loaded into 
+            the card.
+
+   O N L Y !!!  for debugging (no locking against other devices):
+   One raw-data-device with the following functions:
+     write: data to B-channel.
+     read:  data from B-channel.
+
+   In addition the following devices are made available:
+
+   128 tty-devices (64 cuix and 64 ttyIx) with integrated modem-emulator:
+   The functionality is almost the same as that of a serial device
+   (the line-discs are handled by the kernel, which lets you run 
+   SLIP, CSLIP and asynchronous PPP through the devices. We have tested 
+   Seyon, minicom, CSLIP (uri-dip) PPP and mgetty (compiled with NO_FAX),
+   XCept.
+
+   The modem-emulation supports the following:
+           1.3.1 Commands:
+
+               ATA	Answer incoming call.
+	       ATD<No.> Dial, the number may contain:
+                        [0-9] and [,#.*WPT-S]
+                        the latter are ignored until 'S'.
+                        The 'S' must precede the number, if 
+                        the line is a SPV (German 1TR6).
+               ATE0	Echo off.
+	       ATE1     Echo on (default).
+               ATH      Hang-up.
+	       ATH1     Off hook (ignored).
+               ATH0     Hang-up.
+	       ATI      Return "ISDN for Linux...".
+               ATI0        "
+               ATI1        "
+               ATO      On line (data mode).
+               ATQ0     Enable result codes (default).
+               ATQ1     Disable result codes (default).
+               ATSx=y	Set register x to y.
+	       ATSx?    Show contents of register x.
+               ATV0     Numeric responses.
+               ATV1     English responses (default).
+	       ATZ      Load registers and EAZ/MSN from Profile.
+	       AT&Bx    Set Send-Packet-size to x (max. 4000)
+                        The real packet-size may be limited by the
+                        low-level-driver used. i.e.: the Teles-Module-
+                        limit is 2000. You will get NO Error-Message,
+                        if you set it to higher Values, because at the
+                        time of giving this command the corresponding
+                        driver may not be selected (see "Automatic
+                        Assignment") however the size of outgoing packets
+                        will be limited correctly.
+	       AT&D0    Ignore DTR
+	       AT&D2    DTR-low-edge: Hang up and return to 
+                        command mode (default).
+               AT&D3    Same as AT&D2 but also resets all registers.
+	       AT&Ex    Set the EAZ/MSN for this channel to x.
+	       AT&F     Reset all registers and profile to "factory-defaults"
+	       AT&Sx    Set window-size for Teles-driver (x = 1..8) (not yet
+                        implemented)
+	       AT&V     Show all settings.
+               AT&W0    Write registers and EAZ/MSN to profile. See also
+                        iprofd (5.c in this README).
+               AT&X0	BTX-mode off (default)
+	       AT&X1    BTX-mode on. (S13.1=1, S14=0, S16=7, S18=7, S19=0)
+
+           For voice-mode commands refer to README.audio
+
+	   1.3.2 Escape sequence:
+               During a connection, the emulation reacts just like
+               a normal modem to the escape sequence <DELAY>+++<DELAY>.
+	       (The escape character - default '+' - can be set in the
+               register 2).
+               The DELAY must at least be 1.5 seconds long and delay 
+               between the escape characters must not exceed 0.5 seconds.
+     
+           1.3.3 Registers:
+
+              Nr.  Default  Description
+              0    0        Answer on ring number.
+                            (no auto-answer if S0=0).
+              1    0        Count of rings.
+              2    43       Escape character.
+                            (a value >= 128 disables the escape sequence).
+              3    13       Carriage return character (ASCII).
+              4    10       Line feed character (ASCII).
+              5    8        Backspace character (ASCII).
+              6    3        Delay in seconds before dialing.
+              7    60       Wait for carrier (ignored).
+              8    2        Pause time for comma (ignored)
+              9    6        Carrier detect time (ignored)
+             10    7        Carrier loss to disconnect time (ignored).
+             11    70       Touch tone timing (ignored).
+             12    69       Bit coded register:
+                            Bit 0:    0 = Suppress response messages.
+                                      1 = Show response messages.
+                            Bit 1:    0 = English response messages.
+                                      1 = Numeric response messages.
+                            Bit 2:    0 = Echo off.
+                                      1 = Echo on.
+                            Bit 3     0 = DCD always on.
+                                      1 = DCD follows carrier.
+                            Bit 4     0 = CTS follows RTS
+                                      1 = Ignore RTS, CTS always on.
+                            Bit 5     0 = return to command mode on DTR low.
+                                      1 = Same as 0 but also resets all
+                                          registers.
+                                      See also register 13, bit 2
+                            Bit 6     0 = DSR always on.
+                                      1 = DSR only on if channel is available.
+                            Bit 7     0 = Cisco-PPP-flag-hack off (default).
+                                      1 = Cisco-PPP-flag-hack on.
+             13   0         Bit coded register:
+                            Bit 0:    0 = Use delayed tty-send-algorithm
+                                      1 = Direct tty-send.
+                            Bit 1:    0 = T.70 protocol (Only for BTX!) off
+                                      1 = T.70 protocol (Only for BTX!) on
+                            Bit 2:    0 = Don't hangup on DTR low.
+                                      1 = Hangup on DTR low.
+	     14   0         Layer-2 protocol:
+				      0 = X75/LAPB with I-frames
+				      1 = X75/LAPB with UI-frames
+                                      2 = X75/LAPB with BUI-frames
+                                      3 = HDLC
+                                      4 = Transparent (audio)
+             15   0         Layer-3 protocol: (at the moment always 0)
+                                      0 = transparent
+	     16   250       Send-Packet-size/16
+             17   8         Window-size for Teles-driver (not yet implemented)
+             18   4         Bit coded register, Service-Octet-1 to accept,
+                            or to be used on dialout:
+                            Bit 0:    Service 1 (audio) when set.
+                            Bit 1:    Service 5 (BTX) when set.
+                            Bit 2:    Service 7 (data) when set.
+                            Note: It is possible to set more than one
+                                  bit. In this case, on incoming calls
+                                  the selected services are accepted,
+                                  and if the service is "audio", the
+                                  Layer-2-protocol is automatically
+                                  changed to 4 regardless of the setting
+                                  of register 14. On outgoing calls,
+                                  the most significant 1-bit is chosen to
+                                  select the outgoing service octet.
+             19   0         Service-Octet-2
+             20   0         Bit coded register (readonly)
+                            Service-Octet-1 of last call.
+                            Bit mapping is the same like register 18
+
+  Last but not least a (at the moment fairly primitive) device to request
+  the line-status (/dev/isdninfo) is made available.
+
+  Automatic assignment of devices to lines:
+
+  All inactive physical lines are listening to all EAZs for incoming
+  calls and are NOT assigned to a specific tty or network interface.
+  When an incoming call is detected, the driver looks first for a network 
+  interfaces and then for an opened tty which:
+
+  1. is configured for the same EAZ.
+  2. has the same protocol settings for the B-channel.
+  3. (only for network interfaces if the security flag is set)
+     contains the caller number in its access list.
+  4. Either the channel is not bound exclusively to another Net-interface, or
+     it is bound AND the other checks apply to exact this Interface.
+     (For usage of the bind-features, refer to the isdnctrl-man-page)
+
+  Only when a matching interface or tty is found, the call is accepted
+  and the "connection" between the low-level-layer and the link-level-layer
+  is established and kept until the end of the connection.
+  In all other cases no connection is established. Isdn4linux can be
+  configured to either do NOTHING in this case (which is useful, if
+  other, external devices with the same EAZ/MSN are connected to the bus)
+  or to reject the call actively. (isdnctrl busreject ...)
+
+  For an outgoing call, the inactive physical lines are searched.
+  The call is placed on the first physical line, which supports the
+  requested protocols for the B-channel. If a net-interface, however
+  is pre-bound to a channel, this channel is used directly.
+
+  This makes it possible to configure several network interfaces and ttys
+  for one EAZ, if the network interfaces are set to secure operation.
+  If an incoming call matches one network interface, it gets connected to it.
+  If another incoming call for the same EAZ arrives, which does not match
+  a network interface, the first tty gets a "RING" and so on.
+  As soon as voice gets supported (with the availability of the Diehl-driver),
+  the service-identifier will be evaluated in addition.
+
+2 System prerequisites:
+
+  ATTENTION! The program "insmod" from the Package "modules-1.2.8" (It's
+             on nearly all newer distributions) has a bug, which makes
+             it impossible to set both driver-Id's when loading the
+             icn-module for the Double-ICN-Card. A patch is supplied
+             in the utility-package called "insmod-1.2.8.patch". Change into
+             the source-directory of insmod, and type
+             "patch < insmod-1.2.8.patch". Then recompile it. This will fix
+             the bug.
+             This bug does NOT occur when using insmod with the Teles-driver
+             or a single ICN-card.
+ 
+3. Lowlevel-driver configuration.
+
+   Configuration depends on how the drivers are built.
+
+   3.1 Drivers built into the kernel.
+
+     3.1.1 Teles driver.
+
+       The Teles driver can be configured using the commandline-feature
+       while loading the kernel with LILO or LOADLIN. It accepts the
+       following syntax:
+
+       teles=p0,i0,m0,d0[,p1,i1,m1,d1 ... ,pn,in,mn,dn][,idstring]
+
+       where
+
+         p0 = portbase of 1st card.                           (default: 0xd80)
+         i0 = irq of 1st card.                                (default: 15)
+         m0 = shared memory of 1st card.                      (default: 0xd0000)
+         d0 = D-channel protocol of 1st card. 1=1TR6, 2=EDSS1 (default: 2)
+
+         p1,i1,m1,d1 = Parameters of second card (defaults: none)
+         pn,in,mn,d1 = Parameters of n'th card (up to 16 cards are supported)
+
+         idstring = Driver-Id for accessing with utilities and identification
+                    when using a Line-monitor. (default: none)
+                    idstring must start with a character!
+
+         The type of the card is determined by the port, irq and shared memory:
+
+           port == 0, shared memory != 0          -> Teles S0-8
+           port != 0, shared memory != 0          -> Teles S0-16.0
+           port != 0, shared memory == 0          -> Teles S0-16.3
+
+       ATTENTION:
+
+       Due to limited hardware-capabilities, there is no way to check the
+       existence of a card. Therefore you need to be sure your card's setup
+       is correct. Also there are bugs in the printed manual of some newer
+       16.3 cards. Have a look to the kernel-syslog. With most of the cards,
+       you should see a line "HSCX version A:5 B:5" there.
+       
+     3.1.2 ICN driver.
+
+       The ICN driver can be configured using the commandline-feature while
+       loading the kernel with LILO or LOADLIN. It accepts the following
+       syntax
+
+       icn=p,m[,idstring1[,idstring2]]
+
+       where
+
+         p = portbase      (default: 0x320)
+         m = shared memory (default: 0xd0000)
+
+       When using the ICN double card, you MUST define TWO idstrings.
+       idstring must start with a character!
+
+       If you like to use more than one card, you can use the program
+       "icnctrl" from the utility-package to configure additional cards.
+       You need to configure shared memory only once, since the icn-driver
+       maps all cards into the same address-space.
+
+       Using the "icnctrl"-utility, portbase and shared memory can also be
+       changed during runtime.
+
+       The D-channel protocol is configured by loading different firmware
+       into the card's memory using the "icnctrl"-utility.
+
+
+   3.2 Drivers built as modules.
+
+     3.2.1 Teles driver.
+
+       The module teles.o can be configured during "insmod'ing" it by
+       appending its parameters to the insmod-commandline. The following
+       syntax is accepted:
+
+       io=m0,i0,p0,d0[,m1,i1,p1,d1 ... ,mn,in,pn,dn] teles_id=idstring
+
+       where
+
+         m0,i0,p0,d0 ... mn,in,pn,dn have the same meanings like the
+                                     parameters described for the kernel-
+                                     version above. Watch out: different
+                                     sequence!
+
+     3.2.2 ICN driver.
+
+       The module icn.o can be configured during "insmod'ing" it by
+       appending its parameters to the insmod-commandline. The following
+       syntax is accepted:
+
+       portbase=p membase=m icn_id=idstring icn_id2=idstring2
+
+       where p, m, idstring1 and idstring2 have the same meanings like
+                                           parameters described for the kernel-
+                                           version above.
+      
+       When using the ICN double card, you MUST define TWO idstrings.
+       idstring must start with a character!
+
+       Using the "icnctrl"-utility, the same features apply to the modularized
+       version like to the kernel-builtin one.
+
+       The D-channel protocol is configured by loading different firmware
+       into the card's memory using the "icnctrl"-utility.
+
+4. Device-inodes
+
+   The major and minor-numbers and its names are described in
+   Documentation/devices.txt. The major-numbers are:
+
+     43 for the ISDN-tty's.
+     44 for the ISDN-callout-tty's.
+     45 for control/info/debug devices.
+
+
+5. Application
+
+   a) (Only for ICN-cards) Load the firmware into the card:
+
+       cd icn
+     For 1TR6:
+       icnctrl [-d IDstring] load download/loadpg.bin download/pc_1t_ca.bin
+     For Euro-ISDN:
+       icnctrl [-d IDstring] load download/loadpg.bin download/pc_eu_ca.bin
+
+     When using the ICN-4B, the protocol-software for the second half of
+     the card must be appended to the command line.
+
+     -> The two LEDs at the back cover of the card (ICN-4B: 4 LEDs) must be
+        blinking intermittently now. If a connection is up, the corresponding
+        led is lit continuously.
+
+     For loading pcbit-firmware, refer to Documentation/isdn/README.pcbit
+     and the pcbit manpage, included in the utility-package.
+
+   b) If you only intend to use ttys, you are nearly ready now.
+
+   c) If you want to have really permanent "Modem"-settings on disk, you
+      can start the daemon iprofd. Give it a path to a file at the command-
+      line. It will store the profile-settings in this file every time
+      an AT&W0 is performed on any ISDN-tty. If the file already exists,
+      all profiles are initialized from this file. If you want to unload
+      any of the modules, kill iprofd first.
+
+   d) For networking, continue: Create an interface:
+       isdnctrl addif isdn0
+
+   e) Set the EAZ (or MSN for Euro-ISDN):
+       isdnctrl eaz isdn0 2
+
+     (For 1TR6 a single digit is allowed, for Euro-ISDN the number is your
+      real MSN e.g.: Phone-Number)
+
+   f) Set the number for outgoing calls on the interface:
+       isdnctrl addphone isdn0 out 1234567
+       ... (this can be executed more than once, all assigned numbers are
+            tried in order)
+      and the number(s) for incoming calls:
+       isdnctrl addphone isdn0 in 1234567
+
+   g) Set the timeout for hang-up:
+       isdnctrl huptimeout isdn0 <timeout_in_seconds>
+
+   h) additionally you may activate charge-hang-up (= Hang up before 
+      next charge-info, this only works, if your isdn-provider transmits
+      the charge-info during and after the connection, it does NOT work
+      with the Teles on an EDSS1-Line.):
+       isdnctrl chargehup isdn0 on
+
+   i) Setup the interface with ifconfig as usual, and set a route to it.
+
+   j) (optional) If you run X11 and have Tcl/Tk-wish Version4.0, you can use
+     the script tools/tcltk/isdnmon. You can add actions for line-status
+     changes. See the comments at the beginning of the script for how to
+     do that. There are other tty-based tools in the tools-subdirectory
+     contributed by Michael Knigge (imon), Volker Götz (imontty) and
+     Andreas Kool (isdnmon).
+
+   k) For initial testing, you can set the verbose-level to 2 (default: 0).
+      Then all incoming calls are logged, even if they are not addressed
+      to one of the configured net-interfaces:
+      isdnctrl verbose 2
+
+  Now you are ready! A ping to the set address should now result in a
+  dial-out (look at syslog kernel-messages).
+  The phone-numbers and EAZs can be assigned at any time with isdnctrl.
+  You can add as many interfaces as you like with addif following the
+  directions above. Of course, there may be some limitations. But we have 
+  tested as many as 20 interfaces without any problem. However, if you 
+  don't give an interface name to addif, the  kernel will assign a name 
+  which starts with "eth". The number of "eth"-interfaces is limited by
+  the kernel.
+
+5. Additional options for isdnctrl:
+
+   "isdnctrl secure <InterfaceName> on" 
+   Only incoming calls, for which the caller-id is listed in the access
+   list of the interface are accepted. You can add caller-id's With the
+   command "isdnctrl addphone <InterfaceName> in <caller-id>"
+   Euro-ISDN does not transmit the leading '0' of the caller-id for an
+   incoming call, therefore you should configure it accordingly.
+   If the real number for the dialout e.g. is "09311234567" the the number
+   to configure here is "9311234567". The pattern-match function 
+   works similar to the shell mechanism.
+
+     ?     one arbitrary digit
+     *     zero or arbitrary many digits
+     [123] one of the digits in the list
+     [1-5] one digit between '1' and '5'
+           a '^' as the first character in a list inverts the list
+
+
+   "isdnctrl secure <InterfaceName> off" 
+   Switch of secure operation (default).
+
+   "isdnctrl ihup <InterfaceName> [on|off]" 
+   Switch the hang-up-timer for incoming calls on or off.
+
+   "isdnctrl eaz <InterfaceName>" 
+   Returns the EAZ of an interface.
+
+   "isdnctrl delphone <InterfaceName> in|out <number>" 
+   Deletes a number from one of the the access-lists of the interface.
+
+   "isdnctrl delif <InterfaceName>" 
+   Removes the interface (and possible slaves) from the kernel.
+   (You have to unregister it with "ifconfig <InterfaceName> down" before).
+
+   "isdnctrl callback <InterfaceName> [on|off]" 
+   Switches an interface to callback-mode. In this mode, an incoming call
+   will be rejected and after this the remote-station will be called. If
+   you test this feature by using ping, some routers will re-dial very
+   quickly, so that the callback from isdn4linux may not be recognized.
+   In this case use ping with the option -i <sec> to increase the interval
+   between echo-packets.
+
+   "isdnctrl cbdelay <InterfaceName> [seconds]"
+   Sets the delay (default 5 sec) between an incoming call and start of
+   dialing when callback is enabled.
+
+   "isdnctrl cbhup <InterfaceName> [on|off]"
+   This enables (default) or disables an active hangup (reject) when getting an
+   incoming call for an interface which is configured for callback.
+
+   "isdnctrl encap <InterfaceName> <EncapType>"
+   Selects the type of packet-encapsulation. The encapsulation can be changed
+   only while an interface is down.
+
+   At the moment th following Values are supported:
+ 
+   rawip    (Default) Selects raw-IP-encapsulation. This means, MAC-headers
+            are stripped off.  
+   ip       IP with type-field. Same as IP but the type-field of the MAC-header
+            is preserved.
+   cisco-h  A special-mode for communicating with a Cisco, which is configured
+            to do "hdlc"
+   ethernet No stripping. Packets are sent with full MAC-header.
+            The Ethernet-address of the interface is faked, from its
+            IP-address: fc:fc:i1:i2:i3:i4, where i1-4 are the IP-addr.-values.
+   syncppp  Synchronous PPP
+
+   uihdlc   HDLC with UI-frame-header (for use with DOS ISPA, option -h1)
+
+   Watching packets, using standard-tcpdump will fail for all encapsulations
+   except ethernet because tcpdump does not know how to handle packets
+   without MAC-header. A patch for tcpdump is included in the utility-package
+   mentioned above.
+
+   "isdnctrl l2_prot <InterfaceName> <L2-ProtocolName>" 
+   Selects a layer-2-protocol. 
+   (With the ICN-driver and the Teles-driver, "x75i" and "hdlc" is available.
+   With other drivers, "x75ui", "x75bui" may be possible too.)
+
+   isdnctrl l3_prot <InterfaceName> <L3-ProtocolName> 
+   The same for layer-3. (At the moment only "trans" is allowed)
+
+   "isdnctrl list <InterfaceName>" 
+   Shows all parameters of an interface and the charge-info.
+   Try "all" as the interface name.
+
+   "isdnctrl hangup <InterfaceName>"
+   Forces hangup of an interface.
+
+   "isdnctrl bind <InterfaceName> <DriverId>,<ChannelNumber> [exclusive]"
+   If you are using more than one ISDN-Card, it is sometimes necessary to
+   dial out using a specific Card or even preserve a specific Channel for
+   Dialout of a specific net-interface. This can be done with the above
+   command. Replace <DriverId> by whatever you assigned while loading the
+   module. The <ChannelNumber> is counting from zero. the upper Limit
+   depends on the card used. At the Moment no card supports more than
+   2 Channels, so the upper limit is one.
+
+   "isdnctrl unbind <InterfaceName>"
+   unbinds a previously bound interface.
+
+   "isdnctrl busreject <DriverId> on|off"
+   If switched on, isdn4linux replies a REJECT to incoming calls, it
+   cannot match to any configured interface.
+   If switched off, nothing happens in this case.
+   You normally should NOT enable this feature, if the ISDN-adaptor is not
+   the only device, connected to the S0-bus. Otherwise it could happen, that
+   isdn4linux rejects an incoming call, which belongs to another device on
+   the bus. 
+
+   "isdnctrl addslave <InterfaceName> <SlaveName>
+   Creates a slave interface for channel-bundling. Slave interfaces are
+   not seen by the kernel, but their ISDN-part can be configured with
+   isdnctrl as usual. (Phone numbers, EAZ/MSN, timeouts etc.) If more
+   than two channels are to be bundled, feel free to create as many as you
+   want. InterfaceName must be a real interface, NOT a slave. Slave interfaces
+   start dialing, if the master interface resp. the previous slave interface
+   has a load of more than 7000 cps. They hangup if the load goes under 7000
+   cps, according to their "huptimeout"-parameter.
+
+   "isdnctrl sdelay <InterfaceName> secs."
+   This sets the minimum time an Interface has to be fully loaded, until
+   it sends a dial-request to its slave.
+
+   "isdnctrl dial <InterfaceName>"
+   Forces an interface to start dialing even if no packets are to be
+   transferred.
+
+   "isdnctrl mapping <DriverId> MSN0,MSN1,MSN2,...MSN9"
+   This installs a mapping table for EAZ<->MSN-mapping for a single line.
+   Missing MSN's have to be given as "-" or can be omitted, if at the end
+   of the commandline.
+   With this command, it's now possible to have an interface listening to
+   mixed 1TR6- and Euro-Type lines. In this case, the interface has to be
+   configured to a 1TR6-type EAZ (one digit). The mapping is also valid
+   for tty-emulation. Seen from the interface/tty-level the mapping
+   CAN be used, however it's possible to use single tty's/interfaces with
+   real MSN's (more digits) also, in which case the mapping will be ignored.
+   Here is an example:
+
+   You have a 1TR6-type line with base-nr. 1234567 and a Euro-line with
+   MSN's 987654, 987655 and 987656. The DriverId for the Euro-line is "EURO".
+
+   isdnctrl mapping EURO -,987654,987655,987656,-,987655
+   ...
+   isdnctrl eaz isdn0 1      # listen on 12345671(1tr6) and 987654(euro)
+   ...
+   isdnctrl eaz isdn1 4      # listen on 12345674(1tr6) only.
+   ...
+   isdnctrl eaz isdn2 987654 # listen on 987654(euro) only.
+   
+   Same scheme is used with AT&E...  at the tty's.
+  
+6. If you want to write a new low-level-driver, you are welcome.
+   The interface to the link-level-module is described in the file INTERFACE.
+   If the interface should be expanded for any reason, don't do it
+   on your own, send me a mail containing the proposed changes and
+   some reasoning about them.
+   If other drivers will not be affected, I will include the changes
+   in the next release.
+   For developers only, there is a second mailing-list. Write to me
+   (fritz@wuemaus.franken.de), if you want to join that list.
+
+Have fun!
+
+ -Fritz
+
diff --git a/Documentation/isdn/README.audio b/Documentation/isdn/README.audio
new file mode 100644
index 000000000..c2c2d272d
--- /dev/null
+++ b/Documentation/isdn/README.audio
@@ -0,0 +1,119 @@
+$Id: README.audio,v 1.3 1996/06/05 02:19:36 fritz Exp $
+
+ISDN subsystem for Linux.
+  Description of audio mode.
+
+When enabled during kernel configuration, the tty emulator of the ISDN
+subsystem is capable of a reduced set of commands to support audio.
+This document describes the commands supported and the format of
+audio data.
+
+Commands for enabling/disabling audio mode:
+
+        AT+FCLASS=8      Enable audio mode.
+                         This affects the following registers:
+                           S18: Bits 0 and 3 are set.
+                           S16: Set to 48 and any further change to
+                                larger values is blocked.
+        AT+FCLASS=0      Disable audio mode.
+                         Register 18 is set to 4.
+        AT+FCLASS=?      Show possible modes.
+        AT+FCLASS?       Report current mode (0 or 8).
+
+Commands supported in audio mode:
+
+All audio mode commands have the one of the following form:
+
+        AT+Vxx?          Show current setting.
+        AT+Vxx=?         Show possible settings.
+        AT+Vxx=v         Set simple parameter.
+        AT+Vxx=v,v ...   Set complex parameter.
+
+where xx is a two-character code and v are alphanumerical parameters.
+The following commands are supported:
+
+        AT+VNH=x         Auto hangup setting. NO EFFECT, supported
+                         for compatibility only.
+        AT+VNH?          Always reporting "1"
+        AT+VNH=?         Always reporting "1"
+
+        AT+VIP           Reset all audio parameters.
+
+        AT+VLS=x         Line select. x is one of the following:
+                           0 = No device.
+                           2 = Phone line.
+        AT+VLS=?         Always reporting "0,2"
+        AT+VLS?          Show current line.
+
+        AT+VRX           Start recording. Emulator responds with
+                         CONNECT and starts sending audio data to
+                         the application. See below for data format
+
+        AT+VSD=x,y       Set silence-detection parameters.
+                         NO EFFECT, supported for compatibility
+                         only. Possible parameters:
+                           x = 0 ... 31
+                           y = 0 ... 255
+        AT+VSD=?         Report possible parameters.
+        AT+VSD?          Show current parameters.
+
+        AT+VSM=x         Select audio data format.
+                         Possible parameters:
+                           2 = ADPCM-2
+                           3 = ADPCM-3
+                           4 = ADPCM-4
+                           5 = aLAW
+                           6 = uLAW
+        AT+VSM=?         Show possible audio formats.
+
+        AT+VTX           Start audio playback. Emulator responds
+                         with CONNECT and starts sending audio data
+                         received from the application via phone line.
+General behavior and description of data formats/protocol.
+    when a connection is made:
+
+      On incoming calls, if the application responds to a RING
+      with ATA, depending on the calling service, the emulator
+      responds with either CONNECT (data call) or VCON (voice call).
+      
+      On outgoing voice calls, the emulator responds with VCON
+      upon connection setup.
+
+  Audio recording.
+
+    When receiving audio data, a kind of bisync protocol is used.
+    Upon AT+VRX command, the emulator responds with CONNECT, and
+    starts sending audio data to the application. There are several
+    escape sequences defined, all using DLE (0x10) as Escape char:
+
+    <DLE><ETX>              End of audio data. Emulator stops
+                            recording, responding with VCON.
+    <DLE><DLE>              Escape sequence for DLE in data stream.
+    <DLE>0                  Touchtone "0" received.
+         ...
+    <DLE>9                  Touchtone "9" received.
+    <DLE>#                  Touchtone "#" received.
+    <DLE>*                  Touchtone "*" received.
+    <DLE>A                  Touchtone "A" received.
+    <DLE>B                  Touchtone "B" received.
+    <DLE>C                  Touchtone "C" received.
+    <DLE>D                  Touchtone "D" received.
+
+    Currently unsupported DLE sequences:
+
+    <DLE>c                  FAX calling tone received.
+    <DLE>b                  busy tone received.
+    <DLE>q                  quiet. Silence detected after non-silence.
+    <DLE>s                  silence. Silence detected from the
+                            start of recording.
+
+    Any character sent by the application, except XON (0x11) or XOFF (0x13)
+    immediately stops recording.
+
+  Audio playback.
+
+    When sending audio data, upon AT+VTX command, emulator responds with
+    CONNECT, and starts transferring data from application to the phone line.
+    The same DLE sequences apply to this mode.
+
+
diff --git a/Documentation/isdn/README.icn b/Documentation/isdn/README.icn
new file mode 100644
index 000000000..f2dd3ba03
--- /dev/null
+++ b/Documentation/isdn/README.icn
@@ -0,0 +1,64 @@
+$Id: README.icn,v 1.4 1996/06/03 19:57:07 fritz Exp $
+
+You can get the ICN-ISDN-card from:
+
+Thinking Objects Software GmbH
+Obere Heerbergstr. 17
+97078 Würzburg
+Tel: +49 931 2877950
+Fax: +49 931 2877951
+
+email info@think.de
+WWW   http:/www.think.de
+
+
+The card communicates with the PC by two interfaces:
+  1. A range of 4 successive port-addresses, whose base address can be 
+     configured with the switches.
+  2. A memory window with 16KB-256KB size, which can be setup in 16k steps
+     over the whole range of 16MB. Isdn4linux only uses a 16k window.
+     The base address of the window can be configured when loading
+     the lowlevel-module (see README). If using more than one card,
+     all cards are mapped to the same window and activated as needed.
+
+Setting up the IO-address dipswitches for the ICN-ISDN-card:
+
+  Two types of cards exist, one with dip-switches and one with
+  hook-switches.
+
+  1. Setting for the card with hook-switches:
+
+     (0 = switch closed, 1 = switch open)
+
+     S3 S2 S1  Base-address
+      0  0  0  0x300
+      0  0  1  0x310
+      0  1  0  0x320 (Default for isdn4linux)
+      0  1  1  0x330
+      1  0  0  0x340
+      1  0  1  0x350
+      1  1  0  0x360
+      1  1  1  NOT ALLOWED!
+    
+  2. Setting for the card with dip-switches:
+
+     (0 = switch closed, 1 = switch open)
+
+     S1 S2 S3 S4  Base-Address
+      0  0  0  0  0x300
+      0  0  0  1  0x310
+      0  0  1  0  0x320 (Default for isdn4linux)
+      0  0  1  1  0x330
+      0  1  0  0  0x340
+      0  1  0  1  0x350
+      0  1  1  0  0x360
+      0  1  1  1  NOT ALLOWED!
+      1  0  0  0  0x308
+      1  0  0  1  0x318
+      1  0  1  0  0x328
+      1  0  1  1  0x338
+      1  1  0  0  0x348
+      1  1  0  1  0x358
+      1  1  1  0  0x368
+      1  1  1  1  NOT ALLOWED!
+
diff --git a/Documentation/isdn/README.pcbit b/Documentation/isdn/README.pcbit
new file mode 100644
index 000000000..e93562b2c
--- /dev/null
+++ b/Documentation/isdn/README.pcbit
@@ -0,0 +1,40 @@
+------------------------------------------------------------------------------
+ README file for the PCBIT-D Device Driver.
+------------------------------------------------------------------------------
+
+The PCBIT is a Euro ISDN adapter manufactured in Portugal by Octal and
+developed in cooperation with Portugal Telecom and Inesc.
+The driver interfaces with the standard kernel isdn facilities
+originally developed by Fritz Elfert in the isdn4linux project.
+
+The common versions of the pcbit board require a firmware that is 
+distributed (and copyrighted) by the manufacturer. To load this
+firmware you need "pcbitctl" available on the standard isdn4k-utils
+package or in the pcbit package available in:
+
+ftp://ftp.di.fc.ul.pt/pub/systems/Linux/isdn
+
+Known Limitations:
+
+- The board reset proceeding is at the moment incorrect and will only
+allow you to load the firmware after a hard reset.
+
+- Only HDLC in B-channels is supported at the moment. There is now
+current support to X.25 in B or D channels nor LAPD in B
+channels. The main reason is that this two other protocol modes have,
+to my knowledge, very little use. If you want to see them implemented
+*do* send me a mail.
+
+- The driver often triggers errors in the board that i and the
+manufacturer believe to be caused by bugs in the firmware. The current
+version includes several proceedings for error recovery that should
+allow normal operation. Plans for the future include cooperation with
+the manufacturer in order to solve this problems.
+
+Information/hints/help can be obtained in the linux isdn
+mailing list (isdn4linux@hub-wue.franken.de) or directly from me.
+
+regards,
+  Pedro.
+		
+<roque@di.fc.ul.pt>
diff --git a/Documentation/isdn/README.syncppp b/Documentation/isdn/README.syncppp
new file mode 100644
index 000000000..27d260095
--- /dev/null
+++ b/Documentation/isdn/README.syncppp
@@ -0,0 +1,58 @@
+Some additional information for setting up a syncPPP
+connection using network interfaces.
+---------------------------------------------------------------
+
+You need one thing beside the isdn4linux package:
+
+  a patched pppd .. (I called it ipppd to show the difference)
+
+Compiling isdn4linux with sync PPP:
+-----------------------------------
+To compile isdn4linux with the sync PPP part, you have
+to answer the appropriate question when doing a "make config"
+Don't forget to load the slhc.o
+module before the isdn.o module, if VJ-compression support
+is not compiled into your kernel. (e.g if you have no PPP or
+CSLIP in the kernel)
+
+Using isdn4linux with sync PPP:
+-------------------------------
+Sync PPP is just another encapsulation for isdn4linux. The
+name to enable sync PPP encapsulation is 'syncppp' .. e.g:
+
+  /sbin/isdnctrl encap ippp0 syncppp
+
+The name of the interface is here 'ippp0'. You need 
+one interface with the name 'ippp0' to saturate the
+ipppd, which checks the ppp version via this interface.
+Currently, all devices must have the name ipppX where
+'X' is a decimal value.
+
+To set up a PPP connection you need the ipppd .. You must start 
+the ipppd once after installing the modules. The ipppd 
+communicates with the isdn4linux link-level driver using the
+/dev/ippp0 to /dev/ippp15 devices. One ipppd can handle
+all devices at once. If you want to use two PPP connections
+at the same time, you have to connect the ipppd to two
+devices .. and so on. 
+I've implemented one additional option for the ipppd:
+ 'useifip' will get (if set to not 0.0.0.0) the IP address 
+ for the negotiation from the attached network-interface. 
+(also: ipppd will try to negotiate pointopoint IP as remote IP)
+You must disable BSD-compression, this implementation can't
+handle compressed packets.
+
+Check the etc/rc.isdn.syncppp in the isdn4kernel-util package
+for an example setup script.
+
+To use the MPPP stuff, you must configure a slave device
+with isdn4linux. Now call the ipppd with the '+mp' option.
+To increase the number of links, you must use the
+'addlink' option of the isdnctrl tool. (rc.isdn.syncppp.MPPP is
+an example script)
+
+enjoy it,
+    michael
+     
+
+
diff --git a/Documentation/isdn/README.teles b/Documentation/isdn/README.teles
new file mode 100644
index 000000000..904a55925
--- /dev/null
+++ b/Documentation/isdn/README.teles
@@ -0,0 +1,73 @@
+This is my Linux hardware level driver for Teles compatible ISDN cards. It is 
+meant to be used with isdn4isdn4linux, an ISDN Link-level module for Linux written
+by Fritz Elfert.
+
+Isdn4linux can be obtained from ftp.franken.de:/pub/isdn4linux. The most recent 
+Teles driver can be found on my homepage, http://www.xs4all.nl:/~jdo.
+
+Warning
+-------
+Teles4isdn4linux is a work in progress and may crash your machine. It has not 
+been certified and therefore operation on your PTT's ISDN network is probably 
+illegal.
+
+Limitations
+-----------
+Teles4isdn4linux only works on Euro ISDN lines and german 1TR6-lines.
+
+For the B channel transparent (HDLC) protocol and X.75 have been implemented. 
+
+Running
+-------
+When you insmod isdn.o and teles.o (or with the kernel-version, during boottime)
+a few lines should appear in your syslog. Look for something like:
+
+Oct 11 16:53:30 jedi kernel: channels 2
+Oct 11 16:53:31 jedi kernel: Teles module installed
+
+Remember, that according to the new strategy for accessing Low-level-drivers
+from within isdn4linux you should also define a driver-id while doing
+insmod: Simply append teles_id=<SomeString> to the insmod-commandline. This
+string MUST NOT start with a digit or a small 'x'!
+
+At this point you can run a 'cat /dev/isdnctrl0' and view debugging 
+messages. Debugging messages are enabled with the telesctrl tool: 
+
+	teles/telesctrl <DriverId> 1 <debugging_flags>
+
+where <debugging_flags> is the integer sum of the following debugging
+options you wish enabled:
+
+	1   Link-level <--> Hardware-level communication
+	2   Top state machine 
+	4   D channel Q.931 (call control messages)
+	8   D channel Q.921 
+	16  B channel X.75
+	32  Lowlevel (irq and Layer1 stuff)
+
+For example 'teles/telesctrl MyTeles 1 63' enables full 
+debugging.
+
+Questions
+---------
+Check out the FAQ (ftp.franken.de).
+
+Bugs 
+----
+If you find any please let me know. 
+
+Thanks
+------
+Special thanks to:
+
+	Erik Bos,Beat Doebeli,Fritz Elfert,	
+	Pauline Middelink,Paula de Nie, 	
+	Bernd Oerding,Stephan Seidl,Matthias Urlichs, 
+	Rogier Wolff
+
+
+
+Enjoy,
+
+Jan den Ouden   denouden@groovin.xs4all.nl
+
diff --git a/Documentation/isdn/syncPPP.FAQ b/Documentation/isdn/syncPPP.FAQ
new file mode 100644
index 000000000..6813818e0
--- /dev/null
+++ b/Documentation/isdn/syncPPP.FAQ
@@ -0,0 +1,224 @@
+simple isdn4linux PPP FAQ .. to be continued .. not 'debugged' 
+-------------------------------------------------------------------
+
+Q01: what's pppd,ipppd, syncPPP , asyncPPP ??
+Q02: error message "this systems lacks PPP support"
+Q03: strange information using 'ifconfig'
+Q04: MPPP?? What's that and how can I use it ...
+Q05: I tried MPPP but it doesn't work 
+Q06: can I use asynchronous PPP encapsulation with network devices
+Q07: A SunISDN machine can't connect to my i4l system
+Q08: I wanna talk to several machines, which need different configs
+Q09: Starting the ipppd, I get only error messages from i4l
+Q10: I wanna use dynamic IP address assignment 
+Q11: I can't connect. How can I check where the problem is.
+Q12: How can I reduce login delay? 
+
+-------------------------------------------------------------------
+
+Q01: pppd,ipppd, syncPPP , asyncPPP .. what is that ?
+   what should I use?
+A: The pppd is for asynchronous PPP .. asynchronous means
+   here, the framing is character based. (e.g when
+   using ttyI* or tty* devices)
+
+   The ipppd handles PPP packets coming in HDLC
+   frames (bit based protocol) ... The PPP driver
+   in isdn4linux pushes all IP packets direct
+   to the network layer and all PPP protocol
+   frames to the /dev/ippp* device. 
+   So, the ipppd is a simple external network
+   protocol handler.
+
+   If you login into a remote machine using the
+   /dev/ttyI* devices and then enable PPP on the
+   remote terminal server -> use the 'old' pppd
+
+   If your remote side immediately starts to send
+   frames ... you probably connect to a 
+   syncPPP machine .. use the network device part
+   of isdn4linux with the 'syncppp' encapsulation
+   and make sure, that the ipppd is running and 
+   connected to at least one /dev/ippp*. Check the 
+   isdn4linux manual on how to configure a network device.
+
+--
+
+Q02: when I start the ipppd .. I only get the
+   error message "this systems lacks PPP support"
+A: check that at least the device 'ippp0' exists.
+   (you can check this e.g with the program 'ifconfig')
+   The ipppd NEEDS this device under THIS name .. 
+   If this device doesn't exists, use:
+	isdnctrl addif ippp0
+	isdnctrl encap ippp0 syncppp
+	... (see isdn4linux doc for more) ...
+A: Maybe you have compiled the ipppd with another
+   kernel source tree than the kernel you currently
+   run ... 
+
+--
+
+Q03: when I list the netdevices with ifconfig I see, that
+   my ISDN interface has a HWaddr and IRQ=0 and Base 
+   address = 0 
+A: The device is a fake ethernet device .. ignore IRQ and baseaddr
+   You need the HWaddr only for ethernet encapsulation.
+   
+--
+
+Q04: MPPP?? What's that and how can I use it ...
+
+A: MPPP or MP or MPP (Warning: MP is also an 
+   acronym for 'Multi Processor') stands for
+   Multi Point to Point and means bundling
+   of several channels to one logical stream.
+   To enable MPPP negotiation you must call the
+   ipppd with the '+mp' option. 
+   You must also configure a slave device for
+   every additional channel. (see the i4l manual
+   for more)
+   To use channel bundling you must first activate
+   the 'master' or initial call. Now you can add 
+   the slave channels with the command:
+       isdnctrl addlink <device>
+   e.g:
+       isdnctrl addlink ippp0
+   This is different from other encapsulations of
+   isdn4linux! With syncPPP, there is no automatic
+   activation of slave devices.
+
+--
+
+Q05: I tried MPPP but it doesn't work .. the ipppd
+   writes in the debug log something like:
+   .. rcvd [0][proto=0x3d] c0 00 00 00 80 fd 01 01 00 0a ...
+   .. sent [0][LCP ProtRej id=0x2 00 3d c0 00 00 00 80 fd 01 ...
+
+A: you forgot to compile MPPP/RFC1717 support into the
+   ISDN Subsystem. Recompile with this option enabled.
+
+--
+
+Q06: can I use asynchronous PPP encapsulation
+   over the network interface of isdn4linux ..
+
+A: No .. that's not possible .. Use the standard
+   PPP package over the /dev/ttyI* devices. You
+   must not use the ipppd for this.
+   
+--
+
+Q07: A SunISDN machine tries to connect my i4l system,
+   which doesn't work.
+   Checking the debug log I just saw garbage like:
+!![ ... fill in the line ... ]!!
+
+A: The Sun tries to talk asynchronous PPP ... i4l
+   can't understand this ... try to use the ttyI*
+   devices with the standard PPP/pppd package
+
+A: (from Alexanter Strauss: )
+!![ ... fill in mail ]!!
+
+--
+
+Q08: A wanna talk to remote machines, which need
+   a different configuration. The only way
+   I found to do this is to kill the ipppd and
+   start a new one with another config to connect
+   to the second machine. 
+
+A: you must bind a network interface explicitly to
+   an ippp device, where you can connect a (for this
+   interface) individually configured ipppd.
+
+--
+
+Q09: When I start the ipppd I only get error messages
+   from the i4l driver .. 
+
+A: When starting, the ipppd calls functions which may 
+   trigger a network packet. (e.g gethostbyname()).
+   Without the ipppd (at this moment, it is not
+   fully started) we can't handle this network request.
+   Try to configure hostnames necessary for the ipppd
+   in your local /etc/hosts file or in a way, that
+   your system can resolve it without using an
+   isdn/ippp network-interface.
+
+--
+
+Q10: I wanna use dynamic IP address assignment ... How 
+   must I configure the network device.
+
+A: At least you must have a routing, which forwards
+   a packet to the ippp network-interface to trigger
+   the dial-on-demand.
+   A default routing to the ippp-interface will work.
+   Now you must choose a dummy IP address for your
+   interface.
+   If for some reason you can't set the default
+   routing to the ippp interface, you may take any 
+   address of the subnet from which you expect your
+   dynamic IP number and set a 'network route' for
+   this subnet to the ippp interface.
+   To allow overriding of the dummy address you
+   must call the ipppd with the 'ipcp-accept-local' option.
+
+A: You must know, how the ipppd gets the addresses it wanna
+   configure. If you don't give any option, the ipppd
+   tries to negotiate the local host address!
+   With the option 'noipdefault' it requests an address
+   from the remote machine. With 'useifip' it gets the
+   addresses from the net interface. Or you set the address
+   on the option line with the <a.b.c.d:e.f.g.h> option.
+   Note: the IP address of the remote machine must be configured
+   locally or the remote machine must send it in an IPCP request.
+   If your side doesn't know the IP address after negotiation, it
+   closes the connection!
+   You must allow overriding of address with the 'ipcp-accept-*'
+   options, if you have set your own or the remote address 
+   explicitly.
+
+A: Maybe you try these options .. e.g:   
+
+    /sbin/ipppd :$REMOTE noipdefault /dev/ippp0
+
+   where REMOTE must be the address of the remote machine (the
+   machine, which gives you your address)
+
+--
+
+Q11: I can't connect. How can I check where the problem is.
+
+A: A good help log is the debug output from the ipppd...
+   Check whether you can find there:
+   - only a few LCP-conf-req SENT messages (less then 10)
+     and then a Term-REQ:
+     -> check whether your ISDN card is well configured
+        it seems, that your machine doesn't dial
+        (IRQ,IO,Proto, etc problems)
+        Configure your ISDN card to print debug messages and
+        check the /dev/isdnctrl output next time. There
+        you can see, whether there is activity on the card/line.
+   - there are at least a few RECV messages in the log:
+     -> fine: your card is dialing and your remote machine
+        tries to talk with you. Maybe only a missing 
+        authentication. Check your ipppd configuration again.
+   - the ipppd exits for some reason:
+     -> not good ... check /var/adm/syslog and /var/adm/daemon.
+        Could be a bug in the ipppd.
+
+--
+
+Q12: How can I reduce login delay?
+
+A: Log a login session ('debug' log) and check which options 
+  your remote side rejects. Next time configure your ipppd
+  to not negotiate these options. Another 'side effect' is, that
+  this increases redundancy. (e.g your remote side is buggy and
+  rejects options in a wrong way).
+
+
+
diff --git a/Documentation/java.txt b/Documentation/java.txt
new file mode 100644
index 000000000..f5205b1a4
--- /dev/null
+++ b/Documentation/java.txt
@@ -0,0 +1,111 @@
+               Java(tm) Binary Kernel Support for Linux v1.02
+               ----------------------------------------------
+
+Linux beats them ALL! While all other OS's are TALKING about direct
+support of Java Binaries in the OS, Linux is doing it!
+
+You execute Java classes as you would any other executable, after a few
+small details:
+
+	1) You MUST FIRST install the Java Developers Kit for Linux.
+	   The Java on Linux HOWTO gives the details on getting and
+	   installing this. This HOWTO can be found at:
+
+		ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/Java-HOWTO
+
+	   If you install the JDK in a location other than /usr/bin/java,
+	   then you will need to tell the kernel where you put the Java
+	   interpreter.  
+           There are two ways to do this.
+           One, edit fs/binfmt_java.c file and make the needed change to 
+	   the _PATH_JAVA definition at the top of that file.  
+           Two, as root, issue the command:
+	 echo "/path/to/java/interpreter" > /proc/sys/kernel/java-interpreter
+	   (Currently, this does not work if you're using a module for
+	    Java support.)
+
+	2) You must chmod the '*.class' files you wish to execute with
+	   the execute bit. This is not normally (till now) done with
+	   '.class' files.
+
+	3) You must optionally export a CLASSPATH environment variable,
+	   if you plan to use Java applications installed outside of
+	   /usr/local/java/classes/*.
+
+	4) Either compile your kernel with Java support builtin, or
+	   as a loadable module. If a module, load it with insmod or
+	   kerneld.
+
+	5) A caveat.  When executing a java file, the java interpreter is
+	   invoked only with the class name, not with the complete file path.
+	   Therefore it is possible that the file the shell finds with PATH
+	   is not the same file the java interpreter finds with CLASSPATH.
+	   The recommended solution is to make symbolic links from a directory
+	   in PATH to the actual class file in CLASSPATH, e.g.,
+	   /usr/local/bin/myapp -> /usr/local/java/classes/myapp.class.
+
+To test your new setup, enter in the following simple Java app, and name
+it "HelloWorld.java":
+
+	class HelloWorld {
+		public static void main(String args[]) {
+			System.out.println("Hello World!");
+		}
+	}
+
+
+Now compile the application with:
+
+	/usr/local/java/bin/javac HelloWorld.java
+
+Set the executable permissions of the binary file, with:
+
+	chmod 755 HelloWorld.class
+
+And then execute it:
+
+	./HelloWorld.class
+
+
+Yes, it's JUST THAT EASY! ;-)
+
+-----------------------------------------------------------------
+
+Nope, I didn't forget about Java Applets! ;-)
+
+While this may not be the best way to do this, it works!
+
+Take any html file used with the Java appletviewer (like the
+demo/Blink/example1.html file), and:
+
+	1) Insert a new first line of:
+
+		<!--applet-->
+
+	   Make sure the '<' is the first character in the file. This
+	   will be treated as a valid HTML comment outside of this
+	   Java Applet support, so the modified file can still be used
+	   with all known browsers.
+
+	2) If you install the applet viewer in a location other than
+	   /usr/bin/appletviewer, then you will need to tell the
+	   kernel where you put the Java appletviewer.  
+           There are two ways to do this.
+           One, edit fs/binfmt_java.c file and make the needed change to 
+	   the _PATH_APPLET definition at the top of that file.  
+           Two, as root, issue the command:
+	echo "/path/to/java/appletviewer" > /proc/sys/kernel/java-appletviewer
+	   (Currently, this does not work if you're using a module for
+	    Java support.)
+
+	3) You must chmod the '*.html' files you wish to execute with
+	   the execute bit. This is not normally (till now) done with
+	   '.html' files.
+
+	4) And then execute it.
+
+
+Brian A. Lantz
+brian@lantz.com
+(/proc/sys/kernel/java-* support by Mike Shaver (shaver@ingenia.com))
+
diff --git a/Documentation/locks.txt b/Documentation/locks.txt
new file mode 100644
index 000000000..ea91be8a2
--- /dev/null
+++ b/Documentation/locks.txt
@@ -0,0 +1,102 @@
+		      File Locking Release Notes
+
+		Andy Walker <andy@lysaker.kvaerner.no>
+
+			    21 Sep 1996
+
+
+1. What's New?
+--------------
+
+1.1 Flock Emulation Warnings
+----------------------------
+Many people will have noticed the ugly messages that the file locking
+code started generating with the release of kernel version 1.3.95. The
+messages look something like this:
+
+    fcntl_setlk() called by process XX with broken flock() emulation
+
+This is a warning for people using older C libraries that those libraries
+are still calling the pre 1.3.x flock() emulation routines, instead of
+the real flock() system call. The old routines are quite badly broken,
+especially with respect to parent-child lock sharing, and can give bad
+results if, for example, sendmail attempts to use them.
+
+Fixed versions of the C libraries have been on public release for many
+months. The latest versions at the time of writing are 5.3.12 (released)
+or 5.4.6 (testing) for ELF. There is also a 4.7.6 release for people
+using a.out systems.
+
+With the release of Linux 2.0 Linus decided to be lenient on the
+stragglers and changed the warning message so that the kernel will only
+complain once and then shut up. That should make life more bearable even
+for people who, for some reason, don't want to upgrade their libraries.
+
+
+1.2 Disallow Mixed Locks
+------------------------
+
+1.2.1 Sendmail Problems
+---------------------
+Because sendmail was unable to use the old flock() emulation, many sendmail
+installations use fcntl() instead of flock(). This is true of Slackware 3.0
+for example. This gave rise to some other subtle problems if sendmail was
+configured to rebuild the alias file. Sendmail tried to lock the aliases.dir
+file with fcntl() at the same time as the GDBM routines tried to lock this
+file with flock(). With pre 1.3.96 kernels this could result in deadlocks that,
+over time, or under a very heavy mail load, would eventually cause the kernel
+to lock solid with deadlocked processes.
+
+
+1.2.2 The Solution
+------------------
+I have chosen the rather cruel solution of disallowing mixed locking styles
+on a given file at a given time. Attempts to lock a file with flock() when
+fcntl() locks exist, or vice versa, return with an error status of EBUSY.
+This seemed to be the only way to avoid all possible deadlock conditions,
+as flock() locks do not strictly have one owner process and so can't be
+checked for deadlocking in the usual manner.
+
+The process that created a lock with flock() might have forked multiple
+children and exited. Previously the parent process would have been marked
+as the owner of the lock, but deadlocks could just have easily occurred in
+one or more of the children, which we would not have been able to identify
+and avoid.
+
+Some programs may break (again, groan). In particular the aforementioned
+sendmail may have problems running in 'newaliases' mode. It will no longer
+deadlock though. Recompile sendmail to use flock() and your troubles will
+be over.
+
+1.3 Mandatory Locking As A Mount Option
+---------------------------------------
+
+Mandatory locking, as described in 'Documentation/mandatory.txt' was prior
+to this release a general configuration option that was valid for all
+mounted filesystems. This had a number of inherent dangers, not the least
+of which was the ability to freeze an NFS server by asking it to read a
+file for which a mandatory lock existed.
+
+From this release of the kernel, mandatory locking can be turned on and off
+on a per-filesystem basis, using the mount options 'mand' and 'nomand'.
+The default is to disallow mandatory locking. The intention is that
+mandatory locking only be enabled on a local filesystem as the specific need
+arises.
+
+Until an updated version of mount(8) becomes available you may have to apply
+this patch to the mount sources (based on the version distributed with Rick
+Faiths util-linux-2.5 package):
+
+*** mount.c.orig	Sat Jun  8 09:14:31 1996
+--- mount.c	Sat Jun  8 09:13:02 1996
+***************
+*** 100,105 ****
+--- 100,107 ----
+    { "noauto",	0, MS_NOAUTO	},	/* Can  only be mounted explicitly */
+    { "user",	0, MS_USER	},	/* Allow ordinary user to mount */
+    { "nouser",	1, MS_USER	},	/* Forbid ordinary user to mount */
++   { "mand",	0, MS_MANDLOCK	},	/* Allow mandatory locks on this FS */
++   { "nomand",	1, MS_MANDLOCK	},	/* Forbid mandatory locks on this FS */
+    /* add new options here */
+  #ifdef MS_NOSUB
+    { "sub",	1, MS_NOSUB	},	/* allow submounts */
diff --git a/Documentation/logo.txt b/Documentation/logo.txt
new file mode 100644
index 000000000..e85a662cd
--- /dev/null
+++ b/Documentation/logo.txt
@@ -0,0 +1,13 @@
+This is the full-colour version of the currently unofficial Linux logo
+("currently unofficial" just means that there has been no paperwork and
+that I haven't really announced it yet).  It was created by Larry Ewing,
+and is freely usable as long as you acknowledge Larry as the original
+artist. 
+
+Note that there are black-and-white versions of this available that
+scale down to smaller sizes and are better for letterheads or whatever
+you want to use it for: for the full range of logos take a look at
+Larry's web-page:
+
+	http://www.isc.tamu.edu/~lewing/linux/
+
diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt
new file mode 100644
index 000000000..1c28f155f
--- /dev/null
+++ b/Documentation/magic-number.txt
@@ -0,0 +1,63 @@
+This file is a registry of magic numbers which are in use.  When you
+add a magic number to a structure, you should also add it to this
+file, since it is best if the magic numbers used by various structures
+are unique.
+
+It is a *very* good idea to protect kernel data structures with magic
+numbers.  This allows you to check at run time whether (a) a structure
+has been clobbered, or (b) you've passed the wrong structure to a
+routine.  This last is especially useful --- particularly when you are
+passing pointers to structures via a void * pointer.  The tty code,
+for example, does this frequently to pass driver-specific and line
+discipline-specific structures back and forth.
+
+The way to use magic numbers is to declare then at the beginning of
+the structure, like so:
+
+struct tty_ldisc {
+	int	magic;
+	...
+};
+
+Please follow this discipline when you are adding future enhancements
+to the kernel!  It has saved me countless hours of debugging,
+especially in the screwy cases where an array has been overrun and
+structures following the array have been overwritten.  Using this
+discipline, these cases get detected quickly and safely.
+
+					Theodore Ts'o
+					31-Mar-94
+
+The magic table is current to Linux 1.3.98.
+
+					Michael Chastain
+					<mec@duracef.shout.net>
+					6 May 1996
+
+
+
+Magic Name          Number      Structure            File
+===========================================================================
+RISCOM8_MAGIC       0x0907      struct riscom_port   drivers/char/riscom8.h
+APM_BIOS_MAGIC      0x4101      struct apm_struct    include/linux/apm_bios.h
+CYCLADES_MAGIC      0x4359      struct cyclades_port include/linux/cyclades.h
+FASYNC_MAGIC        0x4601      struct fasync_struct include/linux/fs.h
+PTY_MAGIC           0x5001      struct pty_struct    drivers/char/pty.c
+PPP_MAGIC           0x5002      struct ppp_struct    include/linux/if_ppp.h
+SERIAL_MAGIC        0x5301      struct async_struct  include/linux/serial.h
+SLIP_MAGIC          0x5302      struct slip          drivers/net/slip.h
+STRIP_MAGIC         0x5303      struct strip         drivers/net/strip.c
+TTY_MAGIC           0x5401      struct tty_struct    include/linux/tty.h
+TTY_DRIVER_MAGIC    0x5402      struct tty_driver    include/linux/tty_driver.h
+TTY_LDISC_MAGIC     0x5403      struct tty_ldisc     include/linux/tty_ldisc.h
+SCC_MAGIC           0x8530      struct scc_channel   include/linux/scc.h
+ISDN_ASYNC_MAGIC    0x49344C01  modem_info           include/linux/isdn.h
+ISDN_NET_MAGIC      0x49344C02  isdn_net_ndev        include/linux/isdn.h
+STLI_BOARDMAGIC     0x4bc6c825  stlibrd_t            include/linux/istallion.h
+STLI_PORTMAGIC      0xe671c7a1  stliport_t           include/linux/istallion.h
+STL_PANELMAGIC      0x7ef621a1  stlpanel_t           include/linux/stallion.h
+STL_BOARDMAGIC      0xa2267f52  stlbrd_t             include/linux/stallion.h
+STL_PORTMAGIC       0x5a7182c9  stlport_t            include/linux/stallion.h
+PCXX_MAGIC          0x5c6df104  struct channel       drivers/char/pcxx.h
+BAYCOM_MAGIC        0x3105bac0  struct baycom_state  drivers/char/baycom.c
+
diff --git a/Documentation/mandatory.txt b/Documentation/mandatory.txt
new file mode 100644
index 000000000..1ef2788d8
--- /dev/null
+++ b/Documentation/mandatory.txt
@@ -0,0 +1,152 @@
+	Mandatory File Locking For The Linux Operating System
+
+		Andy Walker <andy@lysaker.kvaerner.no>
+
+			   15 April 1996
+
+
+1. What is  mandatory locking?
+------------------------------
+
+Mandatory locking is kernel enforced file locking, as opposed to the more usual
+cooperative file locking used to guarantee sequential access to files among
+processes. File locks are applied using the flock() and fcntl() system calls
+(and the lockf() library routine which is a wrapper around fcntl().) It is
+normally a process' responsibility to check for locks on a file it wishes to
+update, before applying its own lock, updating the file and unlocking it again.
+The most commonly used example of this (and in the case of sendmail, the most
+troublesome) is access to a user's mailbox. The mail user agent and the mail
+transfer agent must guard against updating the mailbox at the same time, and
+prevent reading the mailbox while it is being updated.
+
+In a perfect world all process would use and honour a cooperative, or
+"advisory" locking scheme. However, the world isn't perfect, and there's
+a lot of poorly written code out there.
+
+In trying to address this problem, the designers of System V UNIX came up
+with a "mandatory" locking scheme, whereby the operating system kernel would
+block attempts by a process to write to a file that another process holds a
+"read" -or- "shared" lock on, and block attempts to both read and write to a 
+file that a process holds a "write " -or- "exclusive" lock on.
+
+The System V mandatory locking scheme was intended to have as little impact as
+possible on existing user code. The scheme is based on marking individual files
+as candidates for mandatory locking, and using the existing fcntl()/lockf()
+interface for applying locks just as if they were normal, advisory locks.
+
+Note 1: In saying "file" in the paragraphs above I am actually not telling
+the whole truth. System V locking is based on fcntl(). The granularity of
+fcntl() is such that it allows the locking of byte ranges in files, in addition
+to entire files, so the mandatory locking rules also have byte level
+granularity.
+
+Note 2: POSIX.1 does not specify any scheme for mandatory locking, despite
+borrowing the fcntl() locking scheme from System V. The mandatory locking
+scheme is defined by the System V Interface Definition (SVID) Version 3.
+
+2. Marking a file for mandatory locking
+---------------------------------------
+
+A file is marked as a candidate for mandatory by setting the group-id bit in
+its file mode but removing the group-execute bit. This is an otherwise
+meaningless combination, and was chosen by the System V implementors so as not
+to break existing user programs.
+
+Note that the group-id bit is usually automatically cleared by the kernel when
+a setgid file is written to. This is a security measure. The kernel has been
+modified to recognize the special case of a mandatory lock candidate and to
+refrain from clearing this bit. Similarly the kernel has been modified not
+to run mandatory lock candidates with setgid privileges.
+
+3. Available implementations
+----------------------------
+
+I have considered the implementations of mandatory locking available with
+SunOS 4.1.x, Solaris 2.x and HP-UX 9.x.
+
+Generally I have tried to make the most sense out of the behaviour exhibited
+by these three reference systems. There are many anomalies.
+
+All the reference systems reject all calls to open() for a file on which
+another process has outstanding mandatory locks. This is in direct
+contravention of SVID 3, which states that only calls to open() with the
+O_TRUNC flag set should be rejected. The Linux implementation follows the SVID
+definition, which is the "Right Thing", since only calls with O_TRUNC can
+modify the contents of the file.
+
+HP-UX even disallows open() with O_TRUNC for a file with advisory locks, not
+just mandatory locks. That would appear to contravene POSIX.1.
+
+mmap() is another interesting case. All the operating systems mentioned
+prevent mandatory locks from being applied to an mmap()'ed file, but  HP-UX
+also disallows advisory locks for such a file. SVID actually specifies the
+paranoid HP-UX behaviour.
+
+In my opinion only MAP_SHARED mappings should be immune from locking, and then
+only from mandatory locks - that is what is currently implemented.
+
+SunOS is so hopeless that it doesn't even honour the O_NONBLOCK flag for
+mandatory locks, so reads and writes to locked files always block when they
+should return EAGAIN.
+
+I'm afraid that this is such an esoteric area that the semantics described
+below are just as valid as any others, so long as the main points seem to
+agree. 
+
+4. Semantics
+------------
+
+1. Mandatory locks can only be applied via the fcntl()/lockf() locking
+   interface - in other words the System V/POSIX interface. BSD style
+   locks using flock() never result in a mandatory lock.
+
+2. If a process has locked a region of a file with a mandatory read lock, then
+   other processes are permitted to read from that region. If any of these
+   processes attempts to write to the region it will block until the lock is
+   released, unless the process has opened the file opened with the O_NONBLOCK
+   flag in which case the system call will return immediately with the error
+   status EAGAIN.
+
+3. If a process has locked a region of a file with a mandatory write lock, all
+   attempts to read or write to that region block until the lock is released,
+   unless a process has opened the file with the O_NONBLOCK flag in which case
+   the system call will return immediately with the error status EAGAIN.
+
+4. Calls to open() with O_TRUNC, or to creat(), on a existing file that has
+   any mandatory locks owned by other processes will be rejected with the
+   error status EAGAIN.
+
+5. Attempts to apply a mandatory lock to a file that is memory mapped and
+   shared (via mmap() with MAP_SHARED) will be rejected with the error status
+   EAGAIN.
+
+6. Attempts to create a shared memory map of a file (via mmap() with MAP_SHARED)
+   that has any mandatory locks in effect will be rejected with the error status
+   EAGAIN.
+
+5. Which system calls are affected?
+-----------------------------------
+
+Those which modify a file's contents, not just the inode. That gives read(),
+write(), readv(), writev(), open(), creat(), mmap(), truncate() and
+ftruncate(). truncate() and ftruncate() are considered to be "write" actions
+for the purposes of mandatory locking.
+
+The affected region is usually defined as stretching from the current position
+for the total number of bytes read or written. For the truncate calls it is
+defined as the bytes of a file removed or added (we must also consider bytes
+added, as a lock can specify just "the whole file", rather than a specific
+range of bytes.)
+
+Note 3: I may have overlooked some system calls that need mandatory lock
+checking in my eagerness to get this code out the door. Please let me know, or
+better still fix the system calls yourself and submit a patch to me or Linus.
+
+6. Warning!
+-----------
+
+Not even root can override a mandatory lock, so runaway process can wreak
+havoc if they lock crucial files. The way around it is to change the file
+permissions (remove the setgid bit) before trying to read or write to it.
+Of course, that might be a bit tricky if the system is hung :-(
+
diff --git a/Documentation/modules.txt b/Documentation/modules.txt
new file mode 100644
index 000000000..9fb147ecc
--- /dev/null
+++ b/Documentation/modules.txt
@@ -0,0 +1,215 @@
+This file describes the strategy for dynamically loadable modules
+in the Linux kernel. This is not a technical description on
+the internals of module, but mostly a sample of how to compile
+and use modules.
+
+Note: You should ensure that the modules-X.Y.Z.tar.gz you are using
+is the most up to date one for this kernel. The "X.Y.Z" will reflect
+the kernel version at the time of the release of the modules package.
+Some older modules packages aren't aware of some of the newer modular
+features that the kernel now supports. (If you are unsure, you can 
+usually find out what the current release of the modules-X.Y.Z.tar.gz
+package is by looking up the URL listed for "Bjorn Ekwall" in the 
+file ./linux/CREDITS)
+
+
+In the beginning...
+-------------------
+
+Anyway, your first step is to compile the kernel, as explained in the
+file linux/README.  It generally goes like:
+
+	make config
+	make dep
+	make clean
+	make zImage or make zlilo
+
+In "make config", you select what you want to include in the "resident"
+kernel and what features you want to have available as loadable modules.
+You will generally select the minimal resident set that is needed to boot:
+
+	The filesystem of your root partition
+	A scsi driver, but see below for a list of SCSI modules!
+	Normal hard drive support
+	Net support (CONFIG_NET)
+	TCP/IP support (CONFIG_INET), but no drivers!
+
+	plus those things that you just can't live without...
+
+The set of modules is constantly increasing, and you will be able to select
+the option "m" in "make config" for those features that the current kernel
+can offer as loadable modules.
+
+You also have a possibility to create modules that are less dependent on
+the kernel version.  This option can be selected during "make config", by
+enabling CONFIG_MODVERSIONS, and is most useful on "stable" kernel versions,
+such as the kernels from the 1.2 and 2.0 series.
+If you have modules that are based on sources that are not included in
+the official kernel sources, you will certainly like this option...
+
+Here is a sample of the available modules included in the kernel sources:
+
+	Most filesystems: minix, xiafs, msdos, umsdos, sysv, isofs, hpfs,
+			  smbfs, nfs
+
+	Mid-level SCSI support (required by top and low level scsi drivers).
+	Most low-level SCSI drivers: (i.e. aha1542, in2000)
+	All SCSI high-level drivers: disk, tape, cdrom, generic.
+
+	Most ethernet drivers: (too many to list, please see the file
+				./Documentation/networking/net-modules.txt)
+
+	Most CDROM drivers:
+		aztcd:     Aztech,Orchid,Okano,Wearnes
+		cm206:     Philips/LMS CM206
+		gscd:      Goldstar GCDR-420
+		mcd, mcdx: Mitsumi LU005, FX001
+		optcd:     Optics Storage Dolphin 8000AT
+		sjcd:      Sanyo CDR-H94A
+		sbpcd:     Matsushita/Panasonic CR52x, CR56x, CD200,
+		           Longshine LCS-7260, TEAC CD-55A
+		sonycd535: Sony CDU-531/535, CDU-510/515
+
+	And a lot of misc modules, such as:
+		lp: line printer
+		binfmt_elf: elf loader
+		binfmt_java: java loader
+		isp16: cdrom interface
+		serial: the serial (tty) interface
+
+When you have made the kernel, you create the modules by doing:
+
+	make modules
+
+This will compile all modules and update the linux/modules directory.
+In this directory you will then find a bunch of symbolic links,
+pointing to the various object files in the kernel tree.
+Now, after you have created all your modules, you should also do:
+
+	make modules_install
+
+This will copy all newly made modules into subdirectories under
+"/lib/modules/kernel_release/", where "kernel_release" is something
+like 2.0.1, or whatever the current kernel version is...
+
+As soon as you have rebooted the newly made kernel, you can install
+and remove modules at will with the utilities: "insmod" and "rmmod".
+After reading the man-page for insmod, you will also know how easy
+it is to configure a module when you do "insmod" (hint: symbol=value).
+
+
+Nifty features:
+---------------
+
+You also have access to two utilities: "modprobe" and "depmod", where
+modprobe is a "wrapper" for (or extension to) "insmod".
+These utilities use (and maintain) a set of files that describe all the
+modules that are available for the current kernel in the /lib/modules
+hierarchy as well as their interdependencies.
+
+Using the modprobe utility, you can load any module like this:
+
+	/sbin/modprobe module
+
+without paying much attention to which kernel you are running, or what
+other modules this module depends on.
+
+With the help of the modprobe configuration file: "/etc/conf.modules"
+you can tune the behaviour of modprobe in many ways, including an
+automatic setting of insmod options for each module.
+And, yes, there _are_ man-pages for all this...
+
+To use modprobe successfully, you generally place the following
+command in your /etc/rc.d/rc.S script.  (Read more about this in the
+"rc.hints" file in the module utilities package, "modules-x.y.z.tar.gz".)
+
+	/sbin/depmod -a
+
+This computes the dependencies between the different modules.
+Then if you do, for example
+
+	/sbin/modprobe umsdos
+
+you will automatically load _both_ the msdos and umsdos modules,
+since umsdos runs piggyback on msdos.
+
+
+The "ultimate" utility:
+-----------------------
+
+OK, you have read all of the above, and feel amply impressed...
+Now, we tell you to forget all about how to install and remove
+loadable modules...
+With the kerneld daemon, all of these chores will be taken care of
+automatically.  Just answer "Y" to CONFIG_KERNELD in "make config",
+and make sure that /sbin/kerneld is started as soon as possible
+after boot and that "/sbin/depmod -a" has been executed for the
+current kernel. (Read more about this in the module utilities package.)
+
+Whenever a program wants the kernel to use a feature that is only
+available as a loadable module, and if the kernel hasn't got the
+module installed yet, the kernel will ask the kerneld daemon to take
+care of the situation and make the best of it.
+
+This is what happens:
+
+	- The kernel notices that a feature is requested that is not
+	  resident in the kernel.
+	- The kernel sends a message to kerneld, with a symbolic
+	  description of the requested feature.
+	- The kerneld daemon asks e.g. modprobe to load a module that
+	  fits this symbolic description.
+	- modprobe looks into its internal "alias" translation table
+	  to see if there is a match.  This table can be reconfigured
+	  and expanded by having "alias" lines in "/etc/conf.modules".
+	- insmod is then asked to insert the module(s) that modprobe
+	  has decided that the kernel needs.  Every module will be
+	  configured according to the "options" lines in "/etc/conf.modules".
+	- modprobe exits and kerneld tells the kernel that the request
+	  succeeded (or failed...)
+	- The kernel uses the freshly installed feature just as if it
+	  had been configured into the kernel as a "resident" part.
+
+The icing of the cake is that when an automatically installed module
+has been unused for a period of time (usually 1 minute), the module
+will be automatically removed from the kernel as well.
+
+This makes the kernel use the minimal amount of memory at any given time,
+making it available for more productive use than as just a placeholder for
+unused code.
+
+Actually, this is only a side-effect from the _real_ benefit of kerneld:
+You only have to create a minimal kernel, that is more or less independent
+of the actual hardware setup.  The setup of the "virtual" kernel is
+instead controlled by a configuration file as well as the actual usage
+pattern of the current machine and its kernel.
+This should be good news for maintainers of multiple machines as well as
+for maintainers of distributions.
+
+To use kerneld with the least amount of "hassle", you need modprobe from
+a release that can be considered "recent" w.r.t. your kernel, and also
+a configuration file for modprobe ("/etc/conf.modules").
+Since modprobe already knows about most modules, the minimal configuration
+file could look something like this:
+
+	alias scsi_hostadapter aha1542  # or whatever SCSI adapter you have
+	alias eth0 3c509	# or whatever net adapter you have
+	# you might need an "options" line for some net adapters:
+	options 3c509 io=0x300 irq=10
+	# you might also need an "options" line for some other module:
+	options cdu31a cdu31a_port=0x1f88 sony_pas_init=1
+
+You could add these lines as well, but they are only "cosmetic":
+
+	alias net-pf-3 off	# no ax25 module available (yet)
+	alias net-pf-4 off	# if you don't use the ipx module
+	alias net-pf-5 off	# if you don't use the appletalk module
+
+Finally, for the "purists":
+You can name the modprobe configuration either "/etc/conf.modules" or
+"/etc/modules.conf", since modprobe knows what to do in each case...
+
+
+Written by:
+	Jacques Gelinas <jacques@solucorp.qc.ca>
+	Bjorn Ekwall <bj0rn@blox.se>
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
new file mode 100644
index 000000000..f5182b1c7
--- /dev/null
+++ b/Documentation/networking/00-INDEX
@@ -0,0 +1,31 @@
+00-INDEX
+	- this file
+3c505.txt
+	- information on the 3Com EtherLink Plus (3c505) driver.
+Configurable
+	- info on some of the configurable network parameters
+alias.txt
+	- info on using alias network devices 
+arcnet-hardware.txt
+	- tons of info on arcnet, hubs, arcnet card jumper settings, etc.
+arcnet.txt
+	- info on the using the arcnet driver itself.
+ax25.txt
+	- info on using AX.25 and NET/ROM code for Linux
+framerelay.txt
+	- info on using Frame Relay/Data Link Connection Identifier (DLCI).
+ncsa-telnet
+	- notes on how NCSA telnet (DOS) breaks with MTU discovery enabled.
+net-modules.txt
+	- info and "insmod" parameters for all network driver modules.
+ppp.txt
+	- info on what software you should use to run PPP.
+tcp.txt
+	- short blurb on how TCP output takes place.
+tulip.txt
+	- info on using DEC 21040/21041/21140 based PCI ethernet cards.
+vortex.txt
+	- info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) e'net cards.
+z8530drv.txt
+	- info about Linux driver for Z8530 based HDLC cards for AX.25
+
diff --git a/Documentation/networking/3c505.txt b/Documentation/networking/3c505.txt
new file mode 100644
index 000000000..b9d5b7230
--- /dev/null
+++ b/Documentation/networking/3c505.txt
@@ -0,0 +1,46 @@
+The 3Com Etherlink Plus (3c505) driver.
+
+This driver now uses DMA.  There is currently no support for PIO operation.
+The default DMA channel is 6; this is _not_ autoprobed, so you must
+make sure you configure it correctly.  If loading the driver as a
+module, you can do this with "modprobe 3c505 dma=n".  If the driver is
+linked statically into the kernel, you must either use an "ether="
+statement on the command line, or change the definition of ELP_DMA in 3c505.h.
+
+The driver will warn you if it has to fall back on the compiled in
+default DMA channel. 
+
+If no base address is given at boot time, the driver will autoprobe
+ports 0x300, 0x280 and 0x310 (in that order).  If no IRQ is given, the driver
+will try to probe for it.
+
+The driver can be used as a loadable module.  See net-modules.txt for details
+of the parameters it can take.  
+
+Theoretically, one instance of the driver can now run multiple cards,
+in the standard way (when loading a module, say "modprobe 3c505
+io=0x300,0x340 irq=10,11 dma=6,7" or whatever).  I have not tested
+this, though.
+
+The driver may now support revision 2 hardware; the dependency on
+being able to read the host control register has been removed.  This
+is also untested, since I don't have a suitable card.
+
+Known problems:
+ I still see "DMA upload timed out" messages from time to time.  These
+seem to be fairly non-fatal though.
+ The card is old and slow.
+
+To do:
+ Improve probe/setup code
+ Test multicast and promiscuous operation
+
+Authors:
+ The driver is mainly written by Craig Southeren, email
+ <craigs@ineluki.apana.org.au>.
+ Parts of the driver (adapting the driver to 1.1.4+ kernels,
+ IRQ/address detection, some changes) and this README by
+ Juha Laiho <jlaiho@ichaos.nullnet.fi>.
+ DMA mode, more fixes, etc, by Philip Blundell <pjb27@cam.ac.uk>
+ Multicard support, Software configurable DMA, etc., by
+ Christopher Collins <ccollins@pcug.org.au>
diff --git a/Documentation/networking/Configurable b/Documentation/networking/Configurable
new file mode 100644
index 000000000..48be78ba3
--- /dev/null
+++ b/Documentation/networking/Configurable
@@ -0,0 +1,33 @@
+
+There are a few network parameters that can be tuned to better match
+the kernel to your system hardware and intended usage. The defaults
+are usually a good choice for 99% of the people 99% of the time, but
+you should be aware they do exist and can be changed.
+
+The current list of parameters can be found in the file:
+
+	./linux/net/TUNABLE
+
+Some of these are accessible via the sysctl interface, and many more are
+scheduled to be added in this way. For example, some parameters related 
+to Address Resolution Protocol (ARP) are very easily viewed and altered.
+
+	# cat /proc/sys/net/ipv4/arp_timeout
+	6000
+	# echo 7000 > /proc/sys/net/ipv4/arp_timeout
+	# cat /proc/sys/net/ipv4/arp_timeout
+	7000
+
+Others are already accessible via the related user space programs.
+For example, MAX_WINDOW has a default of 32k which is a good choice for
+modern hardware, but if you have a slow (8 bit) ethercard and/or a slow
+machine, then this will be far too big for the card to keep up with fast 
+Tx'ing machines on the same net, resulting in overruns and receive errors.
+A value of about 4k would be more appropriate, which can be set via:
+
+	# route add -net 192.168.3.0 window 4096
+
+The remainder of these can only be presently changed by altering a #define
+in the related header file. This means an edit and recompile cycle.
+
+						Paul Gortmaker 06/96
diff --git a/Documentation/networking/alias.txt b/Documentation/networking/alias.txt
new file mode 100644
index 000000000..6b742170a
--- /dev/null
+++ b/Documentation/networking/alias.txt
@@ -0,0 +1,92 @@
+NET_ALIAS device aliasing v0.4x
+===============================
+  The main step taken in versions 0.40+ is the implementation of a
+  device aliasing mechanism that creates *actual* devices.
+  This development includes NET_ALIAS (generic aliasing) plus IP_ALIAS
+  (specific IP) support.
+
+Features
+--------
+o  ACTUAL alias devices created & inserted in dev chain
+o  AF_ independent: net_alias_type objects. Generic aliasing engine.
+o  AF_INET optimized
+o  hashed alias address lookup
+o  net_alias_type objs registration/unreg., module-ables.
+o  /proc/net/aliases & /proc/net/alias_types entries
+
+o IP alias implementation: static or runtime module.
+
+Usage (IP aliasing)
+-------------------
+  A very first step to test if you are running a net_alias-ed kernel
+  is to check /proc/net/aliases & /proc/net/alias_types entries:
+     # cat /proc/net/alias*
+
+  For IP aliasing you must have IP_ALIAS support included by
+  static linking ('y' to 2nd question above), or runtime module
+  insertion ('m' to 2nd q. above):
+     # insmod /usr/src/linux/modules/ip_alias.o (1.3.xx)
+     # insmod /usr/src/ip_alias/ip_alias.o      (1.2.xx) see above.
+
+o Alias creation.
+  Alias creation is done by 'magic' iface naming: eg. to create a
+  200.1.1.1 alias for eth0 ...
+  
+    # ifconfig eth0:0 200.1.1.1  etc,etc....
+                   ~~ -> request alias #0 creation (if it not exists) for eth0
+    and routing stuff also ...
+    # route add -host 200.1.1.1 dev eth0:0  (if same IP network as
+					    main device)
+   
+    # route add -net 200.1.1.0 dev eth0:0   (if completely new network wanted
+					    for eth0:0)
+
+o Alias deletion.
+  Also done by magic naming, eg:
+
+    # ifconfig eth0:0-  0  (maybe any address)
+                   ~~~ -> will delete alias (note '-' after dev name)
+  alias device is closed before deletion, so all network stuff that
+  points to it (routes, arp entries, ...) will be released.
+  		   		   
+Alias (re-)configuring
+  Aliases *are* devices, so you configure and refer to them as usual (ifconfig,
+  route, etc).
+  
+o Procfs entries
+  2 entries are added to help fetching alias runtime configuration:
+  a) /proc/net/alias_types
+     Will show you alias_types registered (ie. address families that
+     can be aliased).
+     eg. for IP aliasing with 1 alias configured:
+
+     # cat /proc/net/alias_types
+     type    name            n_attach
+     2       ip              1      
+     
+  b) /proc/net/aliases
+     Will show aliased devices info, eg (same as above):
+
+     # cat /proc/net/aliases
+     device           family address                                
+     eth0:0           2      200.1.1.1
+
+Relationship with main device
+-----------------------------
+  - On main device closing, all aliases will be closed and freed.
+  - Each new alias created is inserted in dev_chain just before next
+    main device (aliases get 'stacked' after main_dev), eg:
+      lo->eth0->eth0:0->eth0:2->eth1->0
+    If eth0 is unregistered, all it aliases will also be:
+      lo->eth1->0     
+
+Contact
+-------
+Please finger or e-mail me:
+   Juan Jose Ciarlante <jjciarla@raiz.uncu.edu.ar>
+   
+		   		
+; local variables:
+; mode: indented-text
+; mode: auto-fill
+; end:
diff --git a/Documentation/networking/arcnet-hardware.txt b/Documentation/networking/arcnet-hardware.txt
new file mode 100644
index 000000000..79d383777
--- /dev/null
+++ b/Documentation/networking/arcnet-hardware.txt
@@ -0,0 +1,3134 @@
+ 
+-----------------------------------------------------------------------------
+1) This file is a supplement to arcnet.txt.  Please read that for general
+   driver configuration help.
+-----------------------------------------------------------------------------
+2) This file is no longer Linux-specific.  It should probably be moved out of
+   the kernel sources.  Ideas?
+-----------------------------------------------------------------------------
+
+Because so many people (myself included) seem to have obtained ARCnet cards
+without manuals, this file contains a quick introduction to ARCnet hardware,
+some cabling tips, and a listing of all jumper settings I can find. Please
+e-mail apenwarr@foxnet.net with any settings for your particular card, or
+any other information you have!
+
+
+INTRODUCTION TO ARCNET
+----------------------
+
+ARCnet is a network type which works in a way similar to popular "ethernet"
+networks but which is also different in some very important ways.
+
+First of all, you can get ARCnet cards in at least two speeds: 2.5Mbps
+(slower than ethernet) and 100Mbps (faster than normal ethernet).  In fact,
+there are others as well, but these are less common.  The different hardware
+types, as far as I'm aware, are not compatible and so you cannot wire a
+100Mbps card to a 2.5Mbps card, and so on.  From what I hear, my driver does
+work with 100Mbps cards, but I haven't been able to verify this myself,
+since I only have the 2.5Mbps variety.  It is probably not going to saturate
+your 100Mbps card.  Stop complaining :)
+
+You also cannot connect an ARCnet card to any kind of ethernet card and
+expect it to work.  
+
+There are two "types" of ARCnet - STAR topology and BUS topology.  This
+refers to how the cards are meant to be wired together.  According to most
+available documentation, you can only connect STAR cards to STAR cards and
+BUS cards to BUS cards.  That makes sense, right?  Well, it's not quite
+true; see below under "Cabling."
+
+Once you get past these little stumbling blocks, ARCnet is actually quite a
+well-designed standard.  It uses something called "modified token passing"
+which makes it completely incompatible with so-called "Token Ring" cards,
+but which makes transfers much more reliable than ethernet does.  In fact,
+ARCnet will guarantee that a packet arrives safely at the destination, and
+even if it can't possibly be delivered properly (ie. because of a cable
+break, or because the destination computer does not exist) it will at least
+tell the sender about it.
+
+Because of the carefully defined action of the "token", it will always make
+a pass around the "ring" within a maximum length of time.  This makes it
+useful for realtime networks.
+
+In addition, all known ARCnet cards have an (almost) identical programming
+interface.  This means that with one "arcnet" driver you can support any
+card; whereas, with ethernet, each manufacturer uses what is sometimes a
+completely different programming interface, leading to a lot of different,
+sometimes very similar, ethernet drivers.  Of course, always using the same
+programming interface also means that when high-performance hardware
+facilities like PCI busmastering DMA appear, it's hard to take advantage of
+them.  Let's not go into that.
+
+One thing that makes ARCnet cards difficult to program for, however, is the
+limit on their packet sizes; standard ARCnet can only send packets that are
+up to 508 bytes in length.  This is smaller than the internet "bare minimum"
+of 576 bytes, let alone the ethernet MTU of 1500.  To compensate, an extra
+level of encapsulation is defined by RFC1201, which I call "packet
+splitting," that allows "virtual packets" to grow as large as 64K each,
+although they are generally kept down to the ethernet-style 1500 bytes.
+
+For more information on the advantages and disadvantages (mostly the
+advantages) of ARCnet networks, you might try the "ARCnet Trade Association"
+WWW page:
+	http://www.arcnet.com
+
+
+CABLING ARCNET NETWORKS
+-----------------------
+
+This section was rewritten by 
+        Vojtech Pavlik     <Vojtech.Pavlik@st.mff.cuni.cz>
+using information from several people, including:
+        Avery Pennraun     <apenwarr@foxnet.net>
+ 	Stephen A. Wood    <saw@hallc1.cebaf.gov>
+ 	John Paul Morrison <jmorriso@bogomips.ee.ubc.ca>
+ 	Joachim Koenig     <jojo@repas.de>
+and Avery touched it up a bit, at Vojtech's request.
+
+ARCnet (the classic 2.5 Mbps version) can be connected by two different
+types of cabling: coax and twisted pair.  The other ARCnet-type networks
+(100 Mbps TCNS and 320 kbps - 32 Mbps ARCnet Plus) use different types of
+cabling (Type1, Fiber, C1, C4, C5).
+
+For a coax network, you "should" use 93 Ohm RG-62 cable.  But other cables
+also work fine, because ARCnet is a very stable network. I personally use 75
+Ohm TV antenna cable.
+
+Cards for coax cabling are shipped in two different variants: for BUS and
+STAR network topologies.  They are mostly the same.  The only difference
+lies in the hybrid chip installed.  BUS cards use high impedance output,
+while STAR use low impedance.  Low impedance card (STAR) is electrically
+equal to a high impedance one with a terminator installed.
+
+Usually, the ARCnet networks are built up from STAR cards and hubs.  There
+are two types of hubs - active and passive.  Passive hubs are small boxes
+with four BNC connectors containing four 47 Ohm resistors:
+
+   |         | wires
+   R         + junction
+-R-+-R-      R 47 Ohm resistors
+   R
+   |
+
+The shielding is connected together.  Active hubs are much more complicated;
+they are powered and contain electronics to amplify the signal and send it
+to other segments of the net.  They usually have eight connectors.  Active
+hubs come in two variants - dumb and smart.  The dumb variant just
+amplifies, but the smart one decodes to digital and encodes back all packets
+coming through.  This is much better if you have several hubs in the net,
+since many dumb active hubs may worsen the signal quality.
+
+And now to the cabling.  What you can connect together:
+
+1. A card to a card.  This is the simplest way of creating a 2-computer
+   network.
+
+2. A card to a passive hub.  Remember that all unused connectors on the hub
+   must be properly terminated with 93 Ohm (or something else if you don't
+   have the right ones) terminators.
+   	(Avery's note: oops, I didn't know that.  Mine (TV cable) works
+	anyway, though.)
+
+3. A card to an active hub.  Here is no need to terminate the unused
+   connectors except some kind of aesthetic feeling.  But, there may not be
+   more than eleven active hubs between any two computers.  That of course
+   doesn't limit the number of active hubs on the network.
+   
+4. An active hub to another.
+
+5. An active hub to passive hub.
+
+Remember, that you can not connect two passive hubs together.  The power loss
+implied by such a connection is too high for the net to operate reliably.
+
+An example of a typical ARCnet network:
+
+           R                     S - STAR type card              
+    S------H--------A-------S    R - Terminator
+           |        |            H - Hub                         
+           |        |            A - Active hub                  
+           |   S----H----S                                       
+           S        |                                            
+                    |                                            
+                    S                                            
+                                                                          
+The BUS topology is very similar to the one used by Ethernet.  The only
+difference is in cable and terminators: they should be 93 Ohm.  Ethernet
+uses 50 Ohm impedance. You use T connectors to put the computers on a single
+line of cable, the bus. You have to put terminators at both ends of the
+cable. A typical BUS ARCnet network looks like:
+
+    RT----T------T------T------T------TR
+     B    B      B      B      B      B
+
+  B - BUS type card
+  R - Terminator
+  T - T connector
+
+But that is not all! The two types can be connected together.  According to
+the official documentation the only way of connecting them is using an active
+hub:
+
+         A------T------T------TR
+         |      B      B      B
+     S---H---S
+         |
+         S
+
+The official docs also state that you can use STAR cards at the ends of
+BUS network in place of a BUS card and a terminator:
+
+     S------T------T------S
+            B      B
+
+But, according to my own experiments, you can simply hang a BUS type card
+anywhere in middle of a cable in a STAR topology network.  And more - you
+can use the bus card in place of any star card if you use a terminator. Then
+you can build very complicated networks fulfilling all your needs!  An
+example:
+
+                                  S
+                                  |
+           RT------T-------T------H------S
+            B      B       B      |
+                                  |       R
+    S------A------T-------T-------A-------H------TR                    
+           |      B       B       |       |      B                         
+           |   S                 BT       |                                 
+           |   |                  |  S----A-----S
+    S------H---A----S             |       | 
+           |   |      S------T----H---S   |
+           S   S             B    R       S  
+                                                               
+A basically different cabling scheme is used with Twisted Pair cabling. Each
+of the TP cards has two RJ (phone-cord style) connectors.  The cards are
+then daisy-chained together using a cable connecting every two neighboring
+cards.  The ends are terminated with RJ 93 Ohm terminators which plug into
+the empty connectors of cards on the ends of the chain.  An example:
+
+          ___________   ___________
+      _R_|_         _|_|_         _|_R_  
+     |     |       |     |       |     |      
+     |Card |       |Card |       |Card |     
+     |_____|       |_____|       |_____|          
+
+
+There are also hubs for the TP topology.  There is nothing difficult
+involved in using them; you just connect a TP chain to a hub on any end or
+even at both.  This way you can create almost any network configuration. 
+The maximum of 11 hubs between any two computers on the net applies here as
+well.  An example:
+
+    RP-------P--------P--------H-----P------P-----PR
+                               |
+      RP-----H--------P--------H-----P------PR
+             |                 |
+             PR                PR
+
+    R - RJ Terminator
+    P - TP Card
+    H - TP Hub
+
+Like any network, ARCnet has a limited cable length.  These are the maximum
+cable lengths between two active ends (an active end being an active hub or
+a STAR card).
+
+		RG-62       93 Ohm up to 650 m
+		RG-59/U     75 Ohm up to 457 m
+		RG-11/U     75 Ohm up to 533 m
+		IBM Type 1 150 Ohm up to 200 m
+		IBM Type 3 100 Ohm up to 100 m
+
+The maximum length of all cables connected to a passive hub is limited to 65
+meters for RG-62 cabling; less for others.  You can see that using passive
+hubs in a large network is a bad idea. The maximum length of a single "BUS
+Trunk" is about 300 meters for RG-62. The maximum distance between the two
+most distant points of the net is limited to 3000 meters. The maximum length
+of a TP cable between two cards/hubs is 650 meters.
+
+
+SETTING THE JUMPERS
+-------------------
+
+All ARCnet cards should have a total of four or five different settings:
+
+  - the I/O address:  this is the "port" your ARCnet card is on.  Probed
+    values in the Linux ARCnet driver are only from 0x200 through 0x3F0. (If
+    your card has additional ones, which is possible, please tell me.) This
+    should not be the same as any other device on your system.  According to
+    a doc I got from Novell, MS Windows prefers values of 0x300 or more,
+    eating net connections on my system (at least) otherwise.  My guess is
+    this may be because, if your card is at 0x2E0, probing for a serial port
+    at 0x2E8 will reset the card and probably mess things up royally.
+	- Avery's favourite: 0x300.
+
+  - the IRQ: on  8-bit cards, it might be 2 (9), 3, 4, 5, or 7.
+             on 16-bit cards, it might be 2 (9), 3, 4, 5, 7, or 10-15.
+             
+    Make sure this is different from any other card on your system.  Note
+    that IRQ2 is the same as IRQ9, as far as Linux is concerned.  You can
+    "cat /proc/interrupts" for a somewhat complete list of which ones are in
+    use at any given time.  Here is a list of common usages from Vojtech
+    Pavlik <Vojtech.Pavlik@st.mff.cuni.cz>:
+    	("Not on bus" means there is no way for a card to generate this
+	interrupt)
+	IRQ  0 - Timer 0 (Not on bus)
+	IRQ  1 - Keyboard (Not on bus)
+	IRQ  2 - IRQ Controller 2 (Not on bus, nor does interrupt the CPU)
+	IRQ  3 - COM2
+	IRQ  4 - COM1
+	IRQ  5 - FREE (LPT2 if you have it; sometimes COM3; maybe PLIP)
+	IRQ  6 - Floppy disk controller
+	IRQ  7 - FREE (LPT1 if you don't use the polling driver; PLIP) 
+	IRQ  8 - Realtime Clock Interrupt (Not on bus)
+	IRQ  9 - FREE (VGA vertical sync interrupt if enabled)
+	IRQ 10 - FREE
+	IRQ 11 - FREE
+	IRQ 12 - FREE
+	IRQ 13 - Numeric Coprocessor (Not on bus)
+	IRQ 14 - Fixed Disk Controller
+	IRQ 15 - FREE (Fixed Disk Controller 2 if you have it) 
+	
+	Note: IRQ 9 is used on some video cards for the "vertical retrace"
+	interrupt.  This interrupt would have been handy for things like
+	video games, as it occurs exactly once per screen refresh, but
+	unfortunately IBM cancelled this feature starting with the original
+	VGA and thus many VGA/SVGA cards do not support it.  For this
+	reason, no modern software uses this interrupt and it can almost
+	always be safely disabled, if your video card supports it at all.
+	
+	If your card for some reason CANNOT disable this IRQ (usually there
+	is a jumper), one solution would be to clip the printed circuit
+	contact on the board: it's the fourth contact from the left on the
+	back side.  I take no responsibility if you try this.
+
+	- Avery's favourite: IRQ2 (actually IRQ9).  Watch that VGA, though.
+
+  - the memory address:  Unlike most cards, ARCnets use "shared memory" for
+    copying buffers around.  Make SURE it doesn't conflict with any other
+    used memory in your system!
+	A0000		- VGA graphics memory (ok if you don't have VGA)
+        B0000		- Monochrome text mode
+        C0000		\  One of these is your VGA BIOS - usually C0000.
+        E0000		/
+        F0000		- System BIOS
+
+    Anything less than 0xA0000 is, well, a BAD idea since it isn't above
+    640k.
+	- Avery's favourite: 0xD0000
+
+  - the station address:  Every ARCnet card has its own "unique" network
+    address from 0 to 255.  Unlike ethernet, you can set this address
+    yourself with a jumper or switch (or on some cards, with special
+    software).  Since it's only 8 bits, you can only have 254 ARCnet cards
+    on a network.  DON'T use 0 or 255, since these are reserved (although
+    neat stuff will probably happen if you DO use them).  By the way, if you
+    haven't already guessed, don't set this the same as any other ARCnet on
+    your network!
+	- Avery's favourite:  3 and 4.  Not that it matters.
+
+  - There may be ETS1 and ETS2 settings.  These may or may not make a
+    difference on your card (many manuals call them "reserved"), but are
+    used to change the delays used when powering up a computer on the
+    network.  This is only necessary when wiring VERY long range ARCnet
+    networks, on the order of 4km or so; in any case, the only real
+    requirement here is that all cards on the network with ETS1 and ETS2
+    jumpers have them in the same position.  Chris Hindy <chrish@io.org>
+    sent in a chart with actual values for this:
+	ET1	ET2	Response Time	Reconfiguration Time
+	---	---	-------------	--------------------
+	open	open	74.7us		840us
+	open	closed	283.4us		1680us
+	closed	open	561.8us		1680us
+	closed	closed	1118.6us	1680us
+    
+    Make sure you set ETS1 and ETS2 to the SAME VALUE for all cards on your
+    network.
+    
+Also, on many cards (not mine, though) there are red and green LED's. 
+Vojtech Pavlik <Vojtech.Pavlik@st.mff.cuni.cz> tells me this is what they
+mean:
+	GREEN           RED             Status
+	-----		---		------
+	OFF             OFF             Power off
+	OFF             Short flashes   Cabling problems (broken cable or not
+					  terminated)
+	OFF (short)     ON              Card init
+	ON              ON              Normal state - everything OK, nothing
+					  happens
+	ON              Long flashes    Data transfer
+	ON              OFF             Never happens (maybe when wrong ID)
+
+
+The following is all the specific information people have sent me about
+their own particular ARCnet cards.  It is officially a mess, and contains
+huge amounts of duplicated information.  I have no time to fix it.  If you
+want to, PLEASE DO!  Just send me a 'diff -u' of all your changes.
+
+The model # is listed right above specifics for that card, so you should be
+able to use your text viewer's "search" function to find the entry you want. 
+If you don't KNOW what kind of card you have, try looking through the
+various diagrams to see if you can tell.
+
+If your model isn't listed and/or has different settings, PLEASE PLEASE
+tell me.  I had to figure mine out without the manual, and it WASN'T FUN!
+
+Even if your ARCnet model isn't listed, but has the same jumpers as another
+model that is, please e-mail me to say so.
+
+Cards Listed in this file (in this order, mostly):
+
+	Manufacturer	Model #			Bits
+	------------	-------			----
+	SMC		PC100			8
+	SMC		PC110			8
+	SMC		PC120			8
+	SMC		PC130			8
+	SMC		PC270E			8
+	SMC		PC500			16
+	SMC		PC500Longboard		16
+	SMC		PC550Longboard		16
+	SMC		PC600			16
+	SMC		PC710			8
+	SMC?		LCS-8830(-T)		8/16
+	Puredata	PDI507			8
+	CNet Tech	CN120-Series		8
+	CNet Tech	CN160-Series		16
+	Lantech?	UM9065L chipset		8
+	Acer		5210-003		8
+	Datapoint?	LAN-ARC-8		8
+	Topware		TA-ARC/10		8
+	Thomas-Conrad	500-6242-0097 REV A	8
+	Waterloo?	(C)1985 Waterloo Micro. 8
+	No Name		--			8/16
+	No Name		Taiwan R.O.C?		8
+	No Name		Model 9058		8
+	Tiara		Tiara Lancard?		8
+	
+
+** SMC = Standard Microsystems Corp.
+** CNet Tech = CNet Technology, Inc.
+
+
+Unclassified Stuff
+------------------
+  - Please send any other information you can find.
+  
+  - And some other stuff (more info is welcome!):
+     From: root@ultraworld.xs4all.nl (Timo Hilbrink)
+     To: apenwarr@foxnet.net (Avery Pennarun)
+     Date: Wed, 26 Oct 1994 02:10:32 +0000 (GMT)
+     Reply-To: timoh@xs4all.nl
+
+     [...parts deleted...]
+
+     About the jumpers: On my PC130 there is one more jumper, located near the
+     cable-connector and it's for changing to star or bus topology; 
+     closed: star - open: bus
+     On the PC500 are some more jumper-pins, one block labeled with RX,PDN,TXI
+     and another with ALE,LA17,LA18,LA19 these are undocumented..
+
+     [...more parts deleted...]
+
+     --- CUT ---
+
+
+** Standard Microsystems Corp (SMC) **
+PC100, PC110, PC120, PC130 (8-bit cards)
+PC500, PC600 (16-bit cards)
+---------------------------------
+  - mainly from Avery Pennarun <apenwarr@foxnet.net>.  Values depicted are
+    from Avery's setup.
+  - special thanks to Timo Hilbrink <timoh@xs4all.nl> for noting that PC120,
+    130, 500, and 600 all have the same switches as Avery's PC100. 
+    PC500/600 have several extra, undocumented pins though. (?)
+  - PC110 settings were verified by Stephen A. Wood <saw@cebaf.gov>
+  - Also, the JP- and S-numbers probably don't match your card exactly.  Try
+    to find jumpers/switches with the same number of settings - it's
+    probably more reliable.
+  
+
+     JP5		       [|]    :    :    :    :
+(IRQ Setting)		      IRQ2  IRQ3 IRQ4 IRQ5 IRQ7
+		Put exactly one jumper on exactly one set of pins.
+
+
+                          1  2   3  4  5  6   7  8  9 10
+     S1                /----------------------------------\
+(I/O and Memory        |  1  1 * 0  0  0  0 * 1  1  0  1  |
+ addresses)            \----------------------------------/
+                          |--|   |--------|   |--------|
+                          (a)       (b)           (m)
+                          
+                WARNING.  It's very important when setting these which way
+                you're holding the card, and which way you think is '1'!
+                
+                If you suspect that your settings are not being made
+		correctly, try reversing the direction or inverting the
+		switch positions.
+
+		a: The first digit of the I/O address.
+			Setting		Value
+			-------		-----
+			00		0
+			01		1
+			10		2
+			11		3
+
+		b: The second digit of the I/O address.
+			Setting		Value
+			-------		-----
+			0000		0
+			0001		1
+			0010		2
+			...		...
+			1110		E
+			1111		F
+
+		The I/O address is in the form ab0.  For example, if
+		a is 0x2 and b is 0xE, the address will be 0x2E0.
+
+		DO NOT SET THIS LESS THAN 0x200!!!!!
+
+
+		m: The first digit of the memory address.
+			Setting		Value
+			-------		-----
+			0000		0
+			0001		1
+			0010		2
+			...		...
+			1110		E
+			1111		F
+
+		The memory address is in the form m0000.  For example, if
+		m is D, the address will be 0xD0000.
+
+		DO NOT SET THIS TO C0000, F0000, OR LESS THAN A0000!
+
+                          1  2  3  4  5  6  7  8
+     S2                /--------------------------\
+(Station Address)      |  1  1  0  0  0  0  0  0  |
+                       \--------------------------/
+
+			Setting		Value
+			-------		-----
+			00000000	00
+			10000000	01
+			01000000	02
+			...
+			01111111	FE
+			11111111	FF
+
+		Note that this is binary with the digits reversed!
+
+		DO NOT SET THIS TO 0 OR 255 (0xFF)!
+
+
+*****************************************************************************
+
+** Standard Microsystems Corp (SMC) **
+PC130E/PC270E (8-bit cards)
+---------------------------
+  - from Juergen Seifert <seifert@htwm.de>
+
+
+STANDARD MICROSYSTEMS CORPORATION (SMC) ARCNET(R)-PC130E/PC270E
+===============================================================
+
+This description has been written by Juergen Seifert <seifert@htwm.de>
+using information from the following Original SMC Manual 
+
+             "Configuration Guide for
+             ARCNET(R)-PC130E/PC270
+            Network Controller Boards
+                Pub. # 900.044A
+                   June, 1989"
+
+ARCNET is a registered trademark of the Datapoint Corporation
+SMC is a registered trademark of the Standard Microsystems Corporation  
+
+The PC130E is an enhanced version of the PC130 board, is equipped with a 
+standard BNC female connector for connection to RG-62/U coax cable.
+Since this board is designed both for point-to-point connection in star
+networks and for connection to bus networks, it is downwardly compatible 
+with all the other standard boards designed for coax networks (that is,
+the PC120, PC110 and PC100 star topology boards and the PC220, PC210 and 
+PC200 bus topology boards).
+
+The PC270E is an enhanced version of the PC260 board, is equipped with two 
+modular RJ11-type jacks for connection to twisted pair wiring.
+It can be used in a star or a daisy-chained network.
+
+
+         8 7 6 5 4 3 2 1
+    ________________________________________________________________
+   |   |       S1        |                                          |
+   |   |_________________|                                          |
+   |    Offs|Base |I/O Addr                                         |
+   |     RAM Addr |                                              ___|
+   |         ___  ___                                       CR3 |___|
+   |        |   \/   |                                      CR4 |___|
+   |        |  PROM  |                                           ___|
+   |        |        |                                        N |   | 8
+   |        | SOCKET |                                        o |   | 7
+   |        |________|                                        d |   | 6
+   |                   ___________________                    e |   | 5
+   |                  |                   |                   A | S | 4
+   |       |oo| EXT2  |                   |                   d | 2 | 3
+   |       |oo| EXT1  |       SMC         |                   d |   | 2
+   |       |oo| ROM   |      90C63        |                   r |___| 1
+   |       |oo| IRQ7  |                   |               |o|  _____|
+   |       |oo| IRQ5  |                   |               |o| | J1  |
+   |       |oo| IRQ4  |                   |              STAR |_____|
+   |       |oo| IRQ3  |                   |                   | J2  |
+   |       |oo| IRQ2  |___________________|                   |_____|
+   |___                                               ______________|
+       |                                             |
+       |_____________________________________________|
+
+Legend:
+
+SMC 90C63	ARCNET Controller / Transceiver /Logic
+S1	1-3:	I/O Base Address Select
+	4-6:	Memory Base Address Select
+	7-8:	RAM Offset Select
+S2	1-8:	Node ID Select
+EXT		Extended Timeout Select
+ROM		ROM Enable Select
+STAR		Selected - Star Topology	(PC130E only)
+		Deselected - Bus Topology	(PC130E only)
+CR3/CR4		Diagnostic LEDs
+J1		BNC RG62/U Connector		(PC130E only)
+J1		6-position Telephone Jack	(PC270E only)
+J2		6-position Telephone Jack	(PC270E only)
+
+Setting one of the switches to Off/Open means "1", On/Closed means "0".
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in group S2 are used to set the node ID.
+These switches work in a way similar to the PC100-series cards; see that
+entry for more information.
+
+
+Setting the I/O Base Address
+----------------------------
+
+The first three switches in switch group S1 are used to select one
+of eight possible I/O Base addresses using the following table
+
+
+   Switch | Hex I/O
+   1 2 3  | Address
+   -------|--------
+   0 0 0  |  260
+   0 0 1  |  290
+   0 1 0  |  2E0  (Manufacturer's default)
+   0 1 1  |  2F0
+   1 0 0  |  300
+   1 0 1  |  350
+   1 1 0  |  380
+   1 1 1  |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer requires 2K of a 16K block of RAM. The base of this
+16K block can be located in any of eight positions.
+Switches 4-6 of switch group S1 select the Base of the 16K block.
+Within that 16K address space, the buffer may be assigned any one of four 
+positions, determined by the offset, switches 7 and 8 of group S1.
+
+   Switch     | Hex RAM | Hex ROM
+   4 5 6  7 8 | Address | Address *)
+   -----------|---------|-----------
+   0 0 0  0 0 |  C0000  |  C2000
+   0 0 0  0 1 |  C0800  |  C2000
+   0 0 0  1 0 |  C1000  |  C2000
+   0 0 0  1 1 |  C1800  |  C2000
+              |         |
+   0 0 1  0 0 |  C4000  |  C6000
+   0 0 1  0 1 |  C4800  |  C6000
+   0 0 1  1 0 |  C5000  |  C6000
+   0 0 1  1 1 |  C5800  |  C6000
+              |         |
+   0 1 0  0 0 |  CC000  |  CE000
+   0 1 0  0 1 |  CC800  |  CE000
+   0 1 0  1 0 |  CD000  |  CE000
+   0 1 0  1 1 |  CD800  |  CE000
+              |         |
+   0 1 1  0 0 |  D0000  |  D2000  (Manufacturer's default)
+   0 1 1  0 1 |  D0800  |  D2000
+   0 1 1  1 0 |  D1000  |  D2000
+   0 1 1  1 1 |  D1800  |  D2000
+              |         |
+   1 0 0  0 0 |  D4000  |  D6000
+   1 0 0  0 1 |  D4800  |  D6000
+   1 0 0  1 0 |  D5000  |  D6000
+   1 0 0  1 1 |  D5800  |  D6000
+              |         |
+   1 0 1  0 0 |  D8000  |  DA000
+   1 0 1  0 1 |  D8800  |  DA000
+   1 0 1  1 0 |  D9000  |  DA000
+   1 0 1  1 1 |  D9800  |  DA000
+              |         |
+   1 1 0  0 0 |  DC000  |  DE000
+   1 1 0  0 1 |  DC800  |  DE000
+   1 1 0  1 0 |  DD000  |  DE000
+   1 1 0  1 1 |  DD800  |  DE000
+              |         |
+   1 1 1  0 0 |  E0000  |  E2000
+   1 1 1  0 1 |  E0800  |  E2000
+   1 1 1  1 0 |  E1000  |  E2000
+   1 1 1  1 1 |  E1800  |  E2000
+  
+*) To enable the 8K Boot PROM install the jumper ROM.
+   The default is jumper ROM not installed.
+
+
+Setting the Timeouts and Interrupt
+----------------------------------
+
+The jumpers labeled EXT1 and EXT2 are used to determine the timeout 
+parameters. These two jumpers are normally left open.
+
+To select a hardware interrupt level set one (only one!) of the jumpers
+IRQ2, IRQ3, IRQ4, IRQ5, IRQ7. The Manufacturer's default is IRQ2.
+ 
+
+Configuring the PC130E for Star or Bus Topology
+-----------------------------------------------
+
+The single jumper labeled STAR is used to configure the PC130E board for 
+star or bus topology.
+When the jumper is installed, the board may be used in a star network, when 
+it is removed, the board can be used in a bus topology.
+
+
+Diagnostic LEDs
+---------------
+
+Two diagnostic LEDs are visible on the rear bracket of the board.
+The green LED monitors the network activity: the red one shows the
+board activity:
+
+ Green  | Status               Red      | Status
+ -------|-------------------   ---------|-------------------
+  on    | normal activity      flash/on | data transfer
+  blink | reconfiguration      off      | no data transfer;
+  off   | defective board or            | incorrect memory or
+        | node ID is zero               | I/O address
+
+
+*****************************************************************************
+
+** Standard Microsystems Corp (SMC) **
+PC500/PC550 Longboard (16-bit cards)
+-------------------------------------
+  - from Juergen Seifert <seifert@htwm.de>
+
+
+STANDARD MICROSYSTEMS CORPORATION (SMC) ARCNET-PC500/PC550 Long Board
+=====================================================================
+
+Note: There is another Version of the PC500 called Short Version, which 
+      is different in hard- and software! The most important differences
+      are:
+      - The long board has no Shared memory.
+      - On the long board the selection of the interrupt is done by binary
+        coded switch, on the short board directly by jumper.
+        
+[Avery's note: pay special attention to that: the long board HAS NO SHARED
+MEMORY.  This means the current Linux-ARCnet driver can't use these cards. 
+I have obtained a PC500Longboard and will be doing some experiments on it in
+the future, but don't hold your breath.  Thanks again to Juergen Seifert for
+his advice about this!]
+
+This description has been written by Juergen Seifert <seifert@htwm.de>
+using information from the following Original SMC Manual 
+
+             "Configuration Guide for
+             SMC ARCNET-PC500/PC550
+         Series Network Controller Boards
+             Pub. # 900.033 Rev. A
+                November, 1989"
+
+ARCNET is a registered trademark of the Datapoint Corporation
+SMC is a registered trademark of the Standard Microsystems Corporation  
+
+The PC500 is equipped with a standard BNC female connector for connection
+to RG-62/U coax cable.
+The board is designed both for point-to-point connection in star networks
+and for connection to bus networks.
+
+The PC550 is equipped with two modular RJ11-type jacks for connection
+to twisted pair wiring.
+It can be used in a star or a daisy-chained (BUS) network.
+
+       1 
+       0 9 8 7 6 5 4 3 2 1     6 5 4 3 2 1
+    ____________________________________________________________________
+   < |         SW1         | |     SW2     |                            |
+   > |_____________________| |_____________|                            |
+   <   IRQ    |I/O Addr                                                 |
+   >                                                                 ___|
+   <                                                            CR4 |___|
+   >                                                            CR3 |___|
+   <                                                                 ___|
+   >                                                              N |   | 8
+   <                                                              o |   | 7
+   >                                                              d | S | 6
+   <                                                              e | W | 5
+   >                                                              A | 3 | 4
+   <                                                              d |   | 3
+   >                                                              d |   | 2
+   <                                                              r |___| 1
+   >                                                        |o|    _____|
+   <                                                        |o|   | J1  |
+   >  3 1                                                   JP6   |_____|
+   < |o|o| JP2                                                    | J2  |
+   > |o|o|                                                        |_____|
+   <  4 2__                                               ______________|
+   >    |  |                                             |
+   <____|  |_____________________________________________|
+
+Legend:
+
+SW1	1-6:	I/O Base Address Select
+	7-10:	Interrupt Select
+SW2	1-6:	Reserved for Future Use
+SW3	1-8:	Node ID Select
+JP2	1-4:	Extended Timeout Select
+JP6		Selected - Star Topology	(PC500 only)
+		Deselected - Bus Topology	(PC500 only)
+CR3	Green	Monitors Network Activity
+CR4	Red	Monitors Board Activity
+J1		BNC RG62/U Connector		(PC500 only)
+J1		6-position Telephone Jack	(PC550 only)
+J2		6-position Telephone Jack	(PC550 only)
+
+Setting one of the switches to Off/Open means "1", On/Closed means "0".
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in group SW3 are used to set the node ID. Each node
+attached to the network must have an unique node ID which must be 
+different from 0.
+Switch 1 serves as the least significant bit (LSB).
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+    Switch | Value
+    -------|-------
+      1    |   1
+      2    |   2
+      3    |   4
+      4    |   8
+      5    |  16
+      6    |  32
+      7    |  64
+      8    | 128
+
+Some Examples:
+
+    Switch         | Hex     | Decimal 
+   8 7 6 5 4 3 2 1 | Node ID | Node ID
+   ----------------|---------|---------
+   0 0 0 0 0 0 0 0 |    not allowed
+   0 0 0 0 0 0 0 1 |    1    |    1 
+   0 0 0 0 0 0 1 0 |    2    |    2
+   0 0 0 0 0 0 1 1 |    3    |    3
+       . . .       |         |
+   0 1 0 1 0 1 0 1 |   55    |   85
+       . . .       |         |
+   1 0 1 0 1 0 1 0 |   AA    |  170
+       . . .       |         |  
+   1 1 1 1 1 1 0 1 |   FD    |  253
+   1 1 1 1 1 1 1 0 |   FE    |  254
+   1 1 1 1 1 1 1 1 |   FF    |  255 
+
+
+Setting the I/O Base Address
+----------------------------
+
+The first six switches in switch group SW1 are used to select one
+of 32 possible I/O Base addresses using the following table
+
+   Switch       | Hex I/O
+   6 5  4 3 2 1 | Address
+   -------------|--------
+   0 1  0 0 0 0 |  200
+   0 1  0 0 0 1 |  210
+   0 1  0 0 1 0 |  220
+   0 1  0 0 1 1 |  230
+   0 1  0 1 0 0 |  240
+   0 1  0 1 0 1 |  250
+   0 1  0 1 1 0 |  260
+   0 1  0 1 1 1 |  270
+   0 1  1 0 0 0 |  280
+   0 1  1 0 0 1 |  290
+   0 1  1 0 1 0 |  2A0
+   0 1  1 0 1 1 |  2B0
+   0 1  1 1 0 0 |  2C0
+   0 1  1 1 0 1 |  2D0
+   0 1  1 1 1 0 |  2E0 (Manufacturer's default)
+   0 1  1 1 1 1 |  2F0
+   1 1  0 0 0 0 |  300
+   1 1  0 0 0 1 |  310
+   1 1  0 0 1 0 |  320
+   1 1  0 0 1 1 |  330
+   1 1  0 1 0 0 |  340
+   1 1  0 1 0 1 |  350
+   1 1  0 1 1 0 |  360
+   1 1  0 1 1 1 |  370
+   1 1  1 0 0 0 |  380
+   1 1  1 0 0 1 |  390
+   1 1  1 0 1 0 |  3A0
+   1 1  1 0 1 1 |  3B0
+   1 1  1 1 0 0 |  3C0
+   1 1  1 1 0 1 |  3D0
+   1 1  1 1 1 0 |  3E0
+   1 1  1 1 1 1 |  3F0
+
+
+Setting the Interrupt
+---------------------
+
+Switches seven through ten of switch group SW1 are used to select the 
+interrupt level. The interrupt level is binary coded, so selections 
+from 0 to 15 would be possible, but only the following eight values will
+be supported: 3, 4, 5, 7, 9, 10, 11, 12.
+
+   Switch   | IRQ
+   10 9 8 7 | 
+   ---------|-------- 
+    0 0 1 1 |  3
+    0 1 0 0 |  4
+    0 1 0 1 |  5
+    0 1 1 1 |  7
+    1 0 0 1 |  9 (=2) (default)
+    1 0 1 0 | 10
+    1 0 1 1 | 11
+    1 1 0 0 | 12
+
+
+Setting the Timeouts 
+--------------------
+
+The two jumpers JP2 (1-4) are used to determine the timeout parameters. 
+These two jumpers are normally left open.
+Refer to the COM9026 Data Sheet for alternate configurations.
+
+
+Configuring the PC500 for Star or Bus Topology
+----------------------------------------------
+
+The single jumper labeled JP6 is used to configure the PC500 board for 
+star or bus topology.
+When the jumper is installed, the board may be used in a star network, when 
+it is removed, the board can be used in a bus topology.
+
+
+Diagnostic LEDs
+---------------
+
+Two diagnostic LEDs are visible on the rear bracket of the board.
+The green LED monitors the network activity: the red one shows the
+board activity:
+
+ Green  | Status               Red      | Status
+ -------|-------------------   ---------|-------------------
+  on    | normal activity      flash/on | data transfer
+  blink | reconfiguration      off      | no data transfer;
+  off   | defective board or            | incorrect memory or
+        | node ID is zero               | I/O address
+
+
+*****************************************************************************
+
+** SMC **
+PC710 (8-bit card)
+------------------
+  - from J.S. van Oosten <jvoosten@compiler.tdcnet.nl>
+  
+Note: this data is gathered by experimenting and looking at info of other
+cards. However, I'm sure I got 99% of the settings right.
+
+The SMC710 card resembles the PC270 card, but is much more basic (i.e. no
+LEDs, RJ11 jacks, etc.) and 8 bit. Here's a little drawing:
+
+    _______________________________________   
+   | +---------+  +---------+              |____
+   | |   S2    |  |   S1    |              |
+   | +---------+  +---------+              |
+   |                                       |
+   |  +===+    __                          |
+   |  | R |   |  | X-tal                 ###___
+   |  | O |   |__|                      ####__'|
+   |  | M |    ||                        ###
+   |  +===+                                |
+   |                                       |
+   |   .. JP1   +----------+               |
+   |   ..       | big chip |               |   
+   |   ..       |  90C63   |               |
+   |   ..       |          |               |
+   |   ..       +----------+               |
+    -------                     -----------
+           |||||||||||||||||||||
+
+The row of jumpers at JP1 actually consists of 8 jumpers, (sometimes
+labelled) the same as on the PC270, from top to bottom: EXT2, EXT1, ROM,
+IRQ7, IRQ5, IRQ4, IRQ3, IRQ2 (gee, wonder what they would do? :-) )
+
+S1 and S2 perform the same function as on the PC270, only their numbers
+are swapped (S1 is the nodeaddress, S2 sets IO- and RAM-address).
+
+I know it works when connected to a PC110 type ARCnet board.
+
+	
+*****************************************************************************
+
+** Possibly SMC **
+LCS-8830(-T) (8 and 16-bit cards)
+---------------------------------
+  - from Mathias Katzer <mkatzer@HRZ.Uni-Bielefeld.DE>
+  - Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl> says the
+    LCS-8830 is slightly different from LCS-8830-T.  These are 8 bit, BUS
+    only (the JP0 jumper is hardwired), and BNC only.
+	
+This is a LCS-8830-T made by SMC, I think ('SMC' only appears on one PLCC,
+nowhere else, not even on the few xeroxed sheets from the manual).
+
+SMC Arcnet Board Type LCS-8830-T
+
+   ------------------------------------
+  |                                    |
+  |              JP3 88  8 JP2         |
+  |       #####      | \               |
+  |       #####    ET1 ET2          ###|
+  |                              8  ###|
+  |  U3   SW 1                  JP0 ###|  Phone Jacks
+  |  --                             ###|
+  | |  |                               |
+  | |  |   SW2                         |
+  | |  |                               |
+  | |  |  #####                        |
+  |  --   #####                       ####  BNC Connector 
+  |                                   ####
+  |   888888 JP1                       |
+  |   234567                           |
+   --                           -------
+     |||||||||||||||||||||||||||
+      --------------------------
+
+
+SW1: DIP-Switches for Station Address
+SW2: DIP-Switches for Memory Base and I/O Base addresses
+
+JP0: If closed, internal termination on (default open)
+JP1: IRQ Jumpers
+JP2: Boot-ROM enabled if closed
+JP3: Jumpers for response timeout
+ 
+U3: Boot-ROM Socket          
+
+
+ET1 ET2     Response Time     Idle Time    Reconfiguration Time
+
+               78                86               840
+ X            285               316              1680
+     X        563               624              1680
+ X   X       1130              1237              1680
+
+(X means closed jumper)
+
+(DIP-Switch downwards means "0")
+
+The station address is binary-coded with SW1.
+
+The I/O base address is coded with DIP-Switches 6,7 and 8 of SW2:
+
+Switches        Base
+678             Address
+000		260-26f
+100		290-29f
+010		2e0-2ef
+110		2f0-2ff
+001		300-30f
+101		350-35f
+011		380-38f
+111 		3e0-3ef
+
+
+DIP Switches 1-5 of SW2 encode the RAM and ROM Address Range:
+
+Switches        Ram           Rom
+12345           Address Range  Address Range
+00000		C:0000-C:07ff	C:2000-C:3fff
+10000		C:0800-C:0fff
+01000		C:1000-C:17ff
+11000		C:1800-C:1fff
+00100		C:4000-C:47ff	C:6000-C:7fff
+10100		C:4800-C:4fff
+01100		C:5000-C:57ff 
+11100		C:5800-C:5fff
+00010		C:C000-C:C7ff	C:E000-C:ffff
+10010		C:C800-C:Cfff
+01010		C:D000-C:D7ff
+11010		C:D800-C:Dfff
+00110		D:0000-D:07ff	D:2000-D:3fff
+10110		D:0800-D:0fff
+01110		D:1000-D:17ff
+11110		D:1800-D:1fff
+00001		D:4000-D:47ff	D:6000-D:7fff
+10001		D:4800-D:4fff
+01001		D:5000-D:57ff
+11001		D:5800-D:5fff
+00101		D:8000-D:87ff	D:A000-D:bfff
+10101		D:8800-D:8fff
+01101		D:9000-D:97ff
+11101		D:9800-D:9fff 
+00011		D:C000-D:c7ff	D:E000-D:ffff
+10011		D:C800-D:cfff
+01011		D:D000-D:d7ff
+11011		D:D800-D:dfff
+00111		E:0000-E:07ff	E:2000-E:3fff
+10111		E:0800-E:0fff
+01111		E:1000-E:17ff
+11111		E:1800-E:1fff
+
+
+*****************************************************************************
+
+** PureData Corp **
+PDI507 (8-bit card)
+--------------------
+  - from Mark Rejhon <mdrejhon@magi.com> (slight modifications by Avery)
+  - Avery's note: I think PDI508 cards (but definitely NOT PDI508Plus cards)
+    are mostly the same as this.  PDI508Plus cards appear to be mainly
+    software-configured.
+
+Jumpers:
+	There is a jumper array at the bottom of the card, near the edge
+        connector.  This array is labelled J1.  They control the IRQs and
+        something else.  Put only one jumper on the IRQ pins.
+
+	ETS1, ETS2 are for timing on very long distance networks.  See the
+	more general information near the top of this file.
+
+	There is a J2 jumper on two pins.  A jumper should be put on them,
+        since it was already there when I got the card.  I don't know what
+        this jumper is for though.
+
+	There is a two-jumper array for J3.  I don't know what it is for,
+        but there were already two jumpers on it when I got the card.  It's
+        a six pin grid in a two-by-three fashion.  The jumpers were
+        configured as follows:
+
+	   .-------.
+	 o | o   o |
+	   :-------:    ------> Accessible end of card with connectors
+	 o | o   o |             in this direction ------->
+	   `-------'
+
+Carl de Billy <CARL@carainfo.com> explains J3 and J4:
+
+	J3 Diagram:
+
+           .-------.
+         o | o   o |
+           :-------:    TWIST Technology
+         o | o   o |
+           `-------'
+           .-------.
+           | o   o | o
+           :-------:    COAX Technology
+           | o   o | o
+           `-------'
+
+  - If using coax cable in a bus topology the J4 jumper must be removed;
+    place it on one pin.
+
+  - If using bus topology with twisted pair wiring move the J3 
+    jumpers so they connect the middle pin and the pins closest to the RJ11
+    Connectors.  Also the J4 jumper must be removed; place it on one pin of
+    J4 jumper for storage.
+
+  - If using  star topology with twisted pair wiring move the J3 
+    jumpers so they connect the middle pin and the pins closest to the RJ11
+    connectors.
+
+
+DIP Switches:
+
+	The dipswitches accessible on the accessible end of the card while
+        it is installed, is used to set the arcnet address.  There are 8
+        switches.  Use an address from 1 to 254.
+
+	Switch No.
+	12345678	Arcnet address
+	-----------------------------------------
+	00000000	FF  	(Don't use this!)
+	00000001	FE
+	00000010	FD
+	....
+	11111101	2	
+	11111110	1
+	11111111	0	(Don't use this!)
+
+	There is another dipswitch array of 8 switches at the top of the
+        card.  There are five labelled MS0-MS4 which seem to control the
+        memory address, and another three labelled IO0-IO2 which seem to
+        control the base I/O address of the card.
+
+	This was difficult to test by trial and error, and the I/O addresses
+        are in a weird order.  This was tested by setting the DIP switches,
+        rebooting the computer, and attempting to load ARCETHER at various
+        addresses (mostly between 0x200 and 0x400).  The address that caused
+        the red transmit LED to blink, is the one that I thought works.
+
+	Also, the address 0x3D0 seem to have a special meaning, since the
+        ARCETHER packet driver loaded fine, but without the red LED
+        blinking.  I don't know what 0x3D0 is for though.  I recommend using
+        an address of 0x300 since Windows may not like addresses below
+        0x300.
+
+	IO Switch No.
+	210             I/O address
+	-------------------------------
+	111             0x260
+	110             0x290
+	101             0x2E0
+	100             0x2F0
+	011             0x300
+	010             0x350
+	001             0x380
+	000             0x3E0
+
+	The memory switches set a reserved address space of 0x1000 bytes
+        (0x100 segment units, or 4k).  For example if I set an address of
+        0xD000, it will use up addresses 0xD000 to 0xD100.
+
+	The memory switches were tested by booting using QEMM386 stealth,
+        and using LOADHI to see what address automatically became excluded
+        from the upper memory regions, and then attempting to load ARCETHER
+        using these addresses.
+
+	I recommend using an arcnet memory address of 0xD000, and putting
+        the EMS page frame at 0xC000 while using QEMM stealth mode.  That
+        way, you get contiguous high memory from 0xD100 almost all the way
+        the end of the megabyte.
+
+	Memory Switch 0 (MS0) didn't seem to work properly when set to OFF
+        on my card.  It could be malfunctioning on my card.  Experiment with
+        it ON first, and if it doesn't work, set it to OFF.  (It may be a
+        modifier for the 0x200 bit?)
+
+	MS Switch No.
+	43210           Memory address
+	--------------------------------
+	00001           0xE100  (guessed - was not detected by QEMM)
+	00011           0xE000  (guessed - was not detected by QEMM)
+	00101           0xDD00
+	00111           0xDC00
+	01001           0xD900
+	01011           0xD800
+	01101           0xD500
+	01111           0xD400
+	10001           0xD100
+	10011           0xD000
+	10101           0xCD00
+	10111           0xCC00
+	11001           0xC900 (guessed - crashes tested system)
+	11011           0xC800 (guessed - crashes tested system)
+	11101           0xC500 (guessed - crashes tested system)
+	11111           0xC400 (guessed - crashes tested system)
+	
+	
+*****************************************************************************
+
+** CNet Technology Inc. **
+120 Series (8-bit cards)
+------------------------
+  - from Juergen Seifert <seifert@htwm.de>
+
+
+CNET TECHNOLOGY INC. (CNet) ARCNET 120A SERIES
+==============================================
+
+This description has been written by Juergen Seifert <seifert@htwm.de>
+using information from the following Original CNet Manual 
+
+              "ARCNET
+            USER'S MANUAL 
+                for
+               CN120A
+               CN120AB
+               CN120TP
+               CN120ST
+               CN120SBT
+             P/N:12-01-0007
+             Revision 3.00"
+
+ARCNET is a registered trademark of the Datapoint Corporation
+
+P/N 120A   ARCNET 8 bit XT/AT Star
+P/N 120AB  ARCNET 8 bit XT/AT Bus
+P/N 120TP  ARCNET 8 bit XT/AT Twisted Pair
+P/N 120ST  ARCNET 8 bit XT/AT Star, Twisted Pair
+P/N 120SBT ARCNET 8 bit XT/AT Star, Bus, Twisted Pair
+
+    __________________________________________________________________
+   |                                                                  |
+   |                                                               ___|
+   |                                                          LED |___|
+   |                                                               ___|
+   |                                                            N |   | ID7
+   |                                                            o |   | ID6
+   |                                                            d | S | ID5
+   |                                                            e | W | ID4
+   |                     ___________________                    A | 2 | ID3
+   |                    |                   |                   d |   | ID2
+   |                    |                   |  1 2 3 4 5 6 7 8  d |   | ID1
+   |                    |                   | _________________ r |___| ID0
+   |                    |      90C65        ||       SW1       |  ____|
+   |  JP 8 7            |                   ||_________________| |    |
+   |    |o|o|  JP1      |                   |                    | J2 |
+   |    |o|o|  |oo|     |                   |         JP 1 1 1   |    |
+   |   ______________   |                   |            0 1 2   |____|
+   |  |  PROM        |  |___________________|           |o|o|o|  _____|
+   |  >  SOCKET      |  JP 6 5 4 3 2                    |o|o|o| | J1  |
+   |  |______________|    |o|o|o|o|o|                   |o|o|o| |_____|
+   |_____                 |o|o|o|o|o|                   ______________|
+         |                                             |
+         |_____________________________________________|
+
+Legend:
+
+90C65       ARCNET Probe
+S1  1-5:    Base Memory Address Select
+    6-8:    Base I/O Address Select
+S2  1-8:    Node ID Select (ID0-ID7)
+JP1     ROM Enable Select
+JP2     IRQ2
+JP3     IRQ3
+JP4     IRQ4
+JP5     IRQ5
+JP6     IRQ7
+JP7/JP8     ET1, ET2 Timeout Parameters
+JP10/JP11   Coax / Twisted Pair Select  (CN120ST/SBT only)
+JP12        Terminator Select       (CN120AB/ST/SBT only)
+J1      BNC RG62/U Connector        (all except CN120TP)
+J2      Two 6-position Telephone Jack   (CN120TP/ST/SBT only)
+
+Setting one of the switches to Off means "1", On means "0".
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in SW2 are used to set the node ID. Each node attached
+to the network must have an unique node ID which must be different from 0.
+Switch 1 (ID0) serves as the least significant bit (LSB).
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+   Switch | Label | Value
+   -------|-------|-------
+     1    | ID0   |   1
+     2    | ID1   |   2
+     3    | ID2   |   4
+     4    | ID3   |   8
+     5    | ID4   |  16
+     6    | ID5   |  32
+     7    | ID6   |  64
+     8    | ID7   | 128
+
+Some Examples:
+
+    Switch         | Hex     | Decimal 
+   8 7 6 5 4 3 2 1 | Node ID | Node ID
+   ----------------|---------|---------
+   0 0 0 0 0 0 0 0 |    not allowed
+   0 0 0 0 0 0 0 1 |    1    |    1 
+   0 0 0 0 0 0 1 0 |    2    |    2
+   0 0 0 0 0 0 1 1 |    3    |    3
+       . . .       |         |
+   0 1 0 1 0 1 0 1 |   55    |   85
+       . . .       |         |
+   1 0 1 0 1 0 1 0 |   AA    |  170
+       . . .       |         |  
+   1 1 1 1 1 1 0 1 |   FD    |  253
+   1 1 1 1 1 1 1 0 |   FE    |  254
+   1 1 1 1 1 1 1 1 |   FF    |  255
+
+
+Setting the I/O Base Address
+----------------------------
+
+The last three switches in switch block SW1 are used to select one
+of eight possible I/O Base addresses using the following table
+
+
+   Switch      | Hex I/O
+    6   7   8  | Address
+   ------------|--------
+   ON  ON  ON  |  260
+   OFF ON  ON  |  290
+   ON  OFF ON  |  2E0  (Manufacturer's default)
+   OFF OFF ON  |  2F0
+   ON  ON  OFF |  300
+   OFF ON  OFF |  350
+   ON  OFF OFF |  380
+   OFF OFF OFF |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer (RAM) requires 2K. The base of this buffer can be 
+located in any of eight positions. The address of the Boot Prom is
+memory base + 8K or memory base + 0x2000.
+Switches 1-5 of switch block SW1 select the Memory Base address.
+
+   Switch              | Hex RAM | Hex ROM
+    1   2   3   4   5  | Address | Address *)
+   --------------------|---------|-----------
+   ON  ON  ON  ON  ON  |  C0000  |  C2000
+   ON  ON  OFF ON  ON  |  C4000  |  C6000
+   ON  ON  ON  OFF ON  |  CC000  |  CE000
+   ON  ON  OFF OFF ON  |  D0000  |  D2000  (Manufacturer's default)
+   ON  ON  ON  ON  OFF |  D4000  |  D6000
+   ON  ON  OFF ON  OFF |  D8000  |  DA000
+   ON  ON  ON  OFF OFF |  DC000  |  DE000
+   ON  ON  OFF OFF OFF |  E0000  |  E2000
+  
+*) To enable the Boot ROM install the jumper JP1
+
+Note: Since the switches 1 and 2 are always set to ON it may be possible
+      that they can be used to add an offset of 2K, 4K or 6K to the base
+      address, but this feature is not documented in the manual and I
+      haven't tested it yet.
+
+
+Setting the Interrupt Line
+--------------------------
+
+To select a hardware interrupt level install one (only one!) of the jumpers
+JP2, JP3, JP4, JP5, JP6. JP2 is the default.
+
+   Jumper | IRQ     
+   -------|-----
+     2    |  2
+     3    |  3
+     4    |  4
+     5    |  5
+     6    |  7
+
+
+Setting the Internal Terminator on CN120AB/TP/SBT
+--------------------------------------------------
+
+The jumper JP12 is used to enable the internal terminator. 
+
+                         -----
+       0                |  0  |     
+     -----   ON         |     |  ON
+    |  0  |             |  0  |
+    |     |  OFF         -----   OFF
+    |  0  |                0
+     -----
+   Terminator          Terminator 
+    disabled            enabled
+  
+
+Selecting the Connector Type on CN120ST/SBT
+-------------------------------------------
+
+     JP10    JP11        JP10    JP11
+                         -----   -----
+       0       0        |  0  | |  0  |       
+     -----   -----      |     | |     |
+    |  0  | |  0  |     |  0  | |  0  |
+    |     | |     |      -----   -----
+    |  0  | |  0  |        0       0 
+     -----   -----
+     Coaxial Cable       Twisted Pair Cable 
+       (Default)
+
+
+Setting the Timeout Parameters
+------------------------------
+
+The jumpers labeled EXT1 and EXT2 are used to determine the timeout 
+parameters. These two jumpers are normally left open.
+
+
+
+*****************************************************************************
+
+** CNet Technology Inc. **
+160 Series (16-bit cards)
+-------------------------
+  - from Juergen Seifert <seifert@htwm.de>
+
+CNET TECHNOLOGY INC. (CNet) ARCNET 160A SERIES
+==============================================
+
+This description has been written by Juergen Seifert <seifert@htwm.de>
+using information from the following Original CNet Manual 
+
+              "ARCNET
+            USER'S MANUAL 
+                for
+               CN160A
+               CN160AB
+               CN160TP
+             P/N:12-01-0006
+             Revision 3.00"
+
+ARCNET is a registered trademark of the Datapoint Corporation
+
+P/N 160A   ARCNET 16 bit XT/AT Star
+P/N 160AB  ARCNET 16 bit XT/AT Bus
+P/N 160TP  ARCNET 16 bit XT/AT Twisted Pair
+
+   ___________________________________________________________________
+  <                             _________________________          ___|
+  >               |oo| JP2     |                         |    LED |___|
+  <               |oo| JP1     |        9026             |    LED |___|
+  >                            |_________________________|         ___|
+  <                                                             N |   | ID7
+  >                                                      1      o |   | ID6
+  <                                    1 2 3 4 5 6 7 8 9 0      d | S | ID5
+  >         _______________           _____________________     e | W | ID4
+  <        |     PROM      |         |         SW1         |    A | 2 | ID3
+  >        >    SOCKET     |         |_____________________|    d |   | ID2
+  <        |_______________|          | IO-Base   | MEM   |     d |   | ID1
+  >                                                             r |___| ID0
+  <                                                               ____|
+  >                                                              |    |
+  <                                                              | J1 |
+  >                                                              |    |
+  <                                                              |____|
+  >                            1 1 1 1                                |
+  <  3 4 5 6 7      JP     8 9 0 1 2 3                                |
+  > |o|o|o|o|o|           |o|o|o|o|o|o|                               |
+  < |o|o|o|o|o| __        |o|o|o|o|o|o|                    ___________|
+  >            |  |                                       |
+  <____________|  |_______________________________________|
+
+Legend:
+
+9026            ARCNET Probe
+SW1 1-6:    Base I/O Address Select
+    7-10:   Base Memory Address Select
+SW2 1-8:    Node ID Select (ID0-ID7)
+JP1/JP2     ET1, ET2 Timeout Parameters
+JP3-JP13    Interrupt Select
+J1      BNC RG62/U Connector        (CN160A/AB only)
+J1      Two 6-position Telephone Jack   (CN160TP only)
+LED
+
+Setting one of the switches to Off means "1", On means "0".
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in SW2 are used to set the node ID. Each node attached
+to the network must have an unique node ID which must be different from 0.
+Switch 1 (ID0) serves as the least significant bit (LSB).
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+   Switch | Label | Value
+   -------|-------|-------
+     1    | ID0   |   1
+     2    | ID1   |   2
+     3    | ID2   |   4
+     4    | ID3   |   8
+     5    | ID4   |  16
+     6    | ID5   |  32
+     7    | ID6   |  64
+     8    | ID7   | 128
+
+Some Examples:
+
+    Switch         | Hex     | Decimal 
+   8 7 6 5 4 3 2 1 | Node ID | Node ID
+   ----------------|---------|---------
+   0 0 0 0 0 0 0 0 |    not allowed
+   0 0 0 0 0 0 0 1 |    1    |    1 
+   0 0 0 0 0 0 1 0 |    2    |    2
+   0 0 0 0 0 0 1 1 |    3    |    3
+       . . .       |         |
+   0 1 0 1 0 1 0 1 |   55    |   85
+       . . .       |         |
+   1 0 1 0 1 0 1 0 |   AA    |  170
+       . . .       |         |  
+   1 1 1 1 1 1 0 1 |   FD    |  253
+   1 1 1 1 1 1 1 0 |   FE    |  254
+   1 1 1 1 1 1 1 1 |   FF    |  255
+
+
+Setting the I/O Base Address
+----------------------------
+
+The first six switches in switch block SW1 are used to select the I/O Base
+address using the following table:
+
+             Switch        | Hex I/O
+    1   2   3   4   5   6  | Address
+   ------------------------|--------
+   OFF ON  ON  OFF OFF ON  |  260
+   OFF ON  OFF ON  ON  OFF |  290
+   OFF ON  OFF OFF OFF ON  |  2E0  (Manufacturer's default)
+   OFF ON  OFF OFF OFF OFF |  2F0
+   OFF OFF ON  ON  ON  ON  |  300
+   OFF OFF ON  OFF ON  OFF |  350
+   OFF OFF OFF ON  ON  ON  |  380
+   OFF OFF OFF OFF OFF ON  |  3E0
+
+Note: Other IO-Base addresses seem to be selectable, but only the above
+      combinations are documented.
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The switches 7-10 of switch block SW1 are used to select the Memory
+Base address of the RAM (2K) and the PROM.
+
+   Switch          | Hex RAM | Hex ROM
+    7   8   9  10  | Address | Address
+   ----------------|---------|-----------
+   OFF OFF ON  ON  |  C0000  |  C8000
+   OFF OFF ON  OFF |  D0000  |  D8000 (Default)
+   OFF OFF OFF ON  |  E0000  |  E8000
+
+Note: Other MEM-Base addresses seem to be selectable, but only the above
+      combinations are documented.
+
+
+Setting the Interrupt Line
+--------------------------
+
+To select a hardware interrupt level install one (only one!) of the jumpers
+JP3 through JP13 using the following table:
+
+   Jumper | IRQ     
+   -------|-----------------
+     3    |  14
+     4    |  15
+     5    |  12
+     6    |  11
+     7    |  10
+     8    |   3
+     9    |   4
+    10    |   5
+    11    |   6
+    12    |   7
+    13    |   2 (=9) Default!
+
+Note:  - Do not use JP11=IRQ6, it may conflict with your Floppy Disk
+         Controller
+       - Use JP3=IRQ14 only, if you don't have an IDE-, MFM-, or RLL-
+         Hard Disk, it may conflict with their controllers
+
+
+Setting the Timeout Parameters
+------------------------------
+
+The jumpers labeled JP1 and JP2 are used to determine the timeout
+parameters. These two jumpers are normally left open.
+
+
+*****************************************************************************
+
+** Lantech **
+8-bit card, unknown model
+-------------------------
+  - from Vlad Lungu <vlungu@ugal.ro> - his e-mail address seemed broken at
+    the time I tried to reach him.  Sorry Vlad, if you didn't get my reply.
+
+   ________________________________________________________________
+   |   1         8                                                 |
+   |   ___________                                               __|
+   |   |   SW1    |                                         LED |__|
+   |   |__________|                                                |
+   |                                                            ___|
+   |                _____________________                       |S | 8
+   |                |                   |                       |W |
+   |                |                   |                       |2 |
+   |                |                   |                       |__| 1
+   |                |      UM9065L      |     |o|  JP4         ____|____
+   |                |                   |     |o|              |  CN    |
+   |                |                   |                      |________|
+   |                |                   |                          |
+   |                |___________________|                          |
+   |                                                               |
+   |                                                               |
+   |      _____________                                            |
+   |      |            |                                           |
+   |      |    PROM    |        |ooooo|  JP6                       |
+   |      |____________|        |ooooo|                            |
+   |_____________                                             _   _|
+                |____________________________________________| |__|
+
+
+UM9065L : Arcnet Controller
+
+SW 1    : Shared Memory Address and I/O Base
+
+        ON=0
+
+        12345|Memory Address
+        -----|--------------
+        00001|  D4000
+        00010|  CC000
+        00110|  D0000
+        01110|  D1000
+        01101|  D9000
+        10010|  CC800
+        10011|  DC800
+        11110|  D1800
+
+It seems that the bits are considered in reverse order.  Also, you must
+observe that some of those addresses are unusual and I didn't probe them; I
+used a memory dump in DOS to identify them.  For the 00000 configuration and
+some others that I didn't write here the card seems to conflict with the
+video card (an S3 GENDAC). I leave the full decoding of those addresses to
+you.
+
+        678| I/O Address
+        ---|------------
+        000|    260
+        001|    failed probe
+        010|    2E0
+        011|    380
+        100|    290
+        101|    350
+        110|    failed probe
+        111|    3E0
+
+SW 2  : Node ID (binary coded)
+
+JP 4  : Boot PROM enable   CLOSE - enabled
+                           OPEN  - disabled
+
+JP 6  : IRQ set (ONLY ONE jumper on 1-5 for IRQ 2-6)
+
+
+*****************************************************************************
+
+** Acer **
+8-bit card, Model 5210-003
+--------------------------
+  - from Vojtech Pavlik <Vojtech.Pavlik@st.mff.cuni.cz> using portions of
+    the existing arcnet-hardware file.
+
+This is a 90C26 based card.  Its configuration seems similar to 
+the SMC PC100, but has some additional jumpers I don't know.
+
+               __
+              |  |
+   ___________|__|_________________________
+  |         |      |                       |
+  |         | BNC  |                       |
+  |         |______|                    ___|
+  |  _____________________             |___  
+  | |                     |                |
+  | | Hybrid IC           |                |
+  | |                     |       o|o J1   |
+  | |_____________________|       8|8      |
+  |                               8|8 J5   |
+  |                               o|o      |
+  |                               8|8      |
+  |__                             8|8      |
+ (|__| LED                        o|o      |
+  |                               8|8      |
+  |                               8|8 J15  |
+  |                                        |
+  |                    _____               |
+  |                   |     |   _____      |
+  |                   |     |  |     |  ___|
+  |                   |     |  |     | |    
+  |  _____            | ROM |  | UFS | |    
+  | |     |           |     |  |     | |   
+  | |     |     ___   |     |  |     | |   
+  | |     |    |   |  |__.__|  |__.__| |   
+  | | NCR |    |XTL|   _____    _____  |   
+  | |     |    |___|  |     |  |     | |   
+  | |90C26|           |     |  |     | |   
+  | |     |           | RAM |  | UFS | |   
+  | |     | J17 o|o   |     |  |     | |   
+  | |     | J16 o|o   |     |  |     | |   
+  | |__.__|           |__.__|  |__.__| |   
+  |  ___                               |   
+  | |   |8                             |   
+  | |SW2|                              |   
+  | |   |                              |   
+  | |___|1                             |   
+  |  ___                               |   
+  | |   |10           J18 o|o          |   
+  | |   |                 o|o          |   
+  | |SW1|                 o|o          |   
+  | |   |             J21 o|o          |   
+  | |___|1                             |   
+  |                                    |   
+  |____________________________________|   
+
+
+Legend:
+
+90C26       ARCNET Chip
+XTL         20 MHz Crystal
+SW1 1-6     Base I/O Address Select
+    7-10    Memory Address Select
+SW2 1-8     Node ID Select (ID0-ID7)
+J1-J5       IRQ Select
+J6-J21      Unknown (Probably extra timeouts & ROM enable ...)
+LED1        Activity LED 
+BNC         Coax connector (STAR arcnet)
+RAM         2k of SRAM
+ROM         Boot ROM socket
+UFS         Unidentified Flying Sockets
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in SW2 are used to set the node ID. Each node attached
+to the network must have an unique node ID which must not be 0.
+Switch 1 (ID0) serves as the least significant bit (LSB).
+
+Setting one of the switches to OFF means "1", ON means "0".
+
+The node ID is the sum of the values of all switches set to "1"
+These values are:
+
+   Switch | Value
+   -------|-------
+     1    |   1
+     2    |   2
+     3    |   4
+     4    |   8
+     5    |  16
+     6    |  32
+     7    |  64
+     8    | 128
+
+Don't set this to 0 or 255; these values are reserved.
+
+
+Setting the I/O Base Address
+----------------------------
+
+The switches 1 to 6 of switch block SW1 are used to select one
+of 32 possible I/O Base addresses using the following tables
+   
+          | Hex
+   Switch | Value
+   -------|-------
+     1    | 200  
+     2    | 100  
+     3    |  80  
+     4    |  40  
+     5    |  20  
+     6    |  10 
+
+The I/O address is sum of all switches set to "1". Remember that
+the I/O address space bellow 0x200 is RESERVED for mainboard, so
+switch 1 should be ALWAYS SET TO OFF. 
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer (RAM) requires 2K. The base of this buffer can be
+located in any of sixteen positions. However, the addresses below
+A0000 are likely to cause system hang because there's main RAM.
+
+Jumpers 7-10 of switch block SW1 select the Memory Base address.
+
+   Switch          | Hex RAM
+    7   8   9  10  | Address
+   ----------------|---------
+   OFF OFF OFF OFF |  F0000 (conflicts with main BIOS)
+   OFF OFF OFF ON  |  E0000 
+   OFF OFF ON  OFF |  D0000
+   OFF OFF ON  ON  |  C0000 (conflicts with video BIOS)
+   OFF ON  OFF OFF |  B0000 (conflicts with mono video)
+   OFF ON  OFF ON  |  A0000 (conflicts with graphics)
+
+
+Setting the Interrupt Line
+--------------------------
+
+Jumpers 1-5 of the jumper block J1 control the IRQ level. ON means 
+shorted, OFF means open.
+
+    Jumper              |  IRQ
+    1   2   3   4   5   |
+   ----------------------------
+    ON  OFF OFF OFF OFF |  7
+    OFF ON  OFF OFF OFF |  5
+    OFF OFF ON  OFF OFF |  4
+    OFF OFF OFF ON  OFF |  3
+    OFF OFF OFF OFF ON  |  2
+
+
+Unknown jumpers & sockets
+-------------------------
+
+I know nothing about these. I just guess that J16&J17 are timeout
+jumpers and maybe one of J18-J21 selects ROM. Also J6-J10 and
+J11-J15 are connecting IRQ2-7 to some pins on the UFSs. I can't
+guess the purpose.
+
+
+*****************************************************************************
+
+** Datapoint? **
+LAN-ARC-8, an 8-bit card
+------------------------
+  - from Vojtech Pavlik <Vojtech.Pavlik@st.mff.cuni.cz>
+
+This is another SMC 90C65 based arcnet card. I couldn't identify the
+manufacturer, but it might be DataPoint, because the card has the
+original arcNet logo in its upper right corner.
+
+          _______________________________________________________
+         |                         _________                     |
+         |                        |   SW2   | ON      arcNet     |
+         |                        |_________| OFF             ___|
+         |  _____________         1 ______  8                |   | 8  
+         | |             | SW1     | XTAL | ____________     | S |    
+         | > RAM (2k)    |         |______||            |    | W |    
+         | |_____________|                 |      H     |    | 3 |    
+         |                        _________|_____ y     |    |___| 1  
+         |  _________            |         |     |b     |        |    
+         | |_________|           |         |     |r     |        |    
+         |                       |     SMC |     |i     |        |    
+         |                       |    90C65|     |d     |        |      
+         |  _________            |         |     |      |        |
+         | |   SW1   | ON        |         |     |I     |        |
+         | |_________| OFF       |_________|_____/C     |   _____|
+         |  1       8                      |            |  |     |___
+         |  ______________                 |            |  | BNC |___|
+         | |              |                |____________|  |_____|
+         | > EPROM SOCKET |              _____________           |
+         | |______________|             |_____________|          |
+         |                                         ______________|
+         |                                        | 
+         |________________________________________|
+
+Legend:
+
+90C65       ARCNET Chip 
+SW1 1-5:    Base Memory Address Select
+    6-8:    Base I/O Address Select
+SW2 1-8:    Node ID Select
+SW3 1-5:    IRQ Select   
+    6-7:    Extra Timeout
+    8  :    Rom Enable   
+BNC         Coax connector
+XTAL        20MHz Crystal
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in SW3 are used to set the node ID. Each node attached
+to the network must have an unique node ID which must not be 0.
+Switch 1 serves as the least significant bit (LSB).
+
+Setting one of the switches to Off means "1", On means "0".
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+   Switch | Value
+   -------|-------
+     1    |   1
+     2    |   2
+     3    |   4
+     4    |   8
+     5    |  16
+     6    |  32
+     7    |  64
+     8    | 128
+
+
+Setting the I/O Base Address
+----------------------------
+
+The last three switches in switch block SW1 are used to select one
+of eight possible I/O Base addresses using the following table
+
+
+   Switch      | Hex I/O
+    6   7   8  | Address
+   ------------|--------
+   ON  ON  ON  |  260
+   OFF ON  ON  |  290
+   ON  OFF ON  |  2E0  (Manufacturer's default)
+   OFF OFF ON  |  2F0
+   ON  ON  OFF |  300
+   OFF ON  OFF |  350
+   ON  OFF OFF |  380
+   OFF OFF OFF |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer (RAM) requires 2K. The base of this buffer can be 
+located in any of eight positions. The address of the Boot Prom is
+memory base + 0x2000.
+Jumpers 3-5 of switch block SW1 select the Memory Base address.
+
+   Switch              | Hex RAM | Hex ROM
+    1   2   3   4   5  | Address | Address *)
+   --------------------|---------|-----------
+   ON  ON  ON  ON  ON  |  C0000  |  C2000
+   ON  ON  OFF ON  ON  |  C4000  |  C6000
+   ON  ON  ON  OFF ON  |  CC000  |  CE000
+   ON  ON  OFF OFF ON  |  D0000  |  D2000  (Manufacturer's default)
+   ON  ON  ON  ON  OFF |  D4000  |  D6000
+   ON  ON  OFF ON  OFF |  D8000  |  DA000
+   ON  ON  ON  OFF OFF |  DC000  |  DE000
+   ON  ON  OFF OFF OFF |  E0000  |  E2000
+  
+*) To enable the Boot ROM set the switch 8 of switch block SW3 to position ON.
+
+The switches 1 and 2 probably add 0x0800 and 0x1000 to RAM base address.
+
+
+Setting the Interrupt Line
+--------------------------
+
+Switches 1-5 of the switch block SW3 control the IRQ level.
+
+    Jumper              |  IRQ
+    1   2   3   4   5   |
+   ----------------------------
+    ON  OFF OFF OFF OFF |  3
+    OFF ON  OFF OFF OFF |  4
+    OFF OFF ON  OFF OFF |  5
+    OFF OFF OFF ON  OFF |  7
+    OFF OFF OFF OFF ON  |  2
+
+
+Setting the Timeout Parameters
+------------------------------
+
+The switches 6-7 of the switch block SW3 are used to determine the timeout
+parameters.  These two switches are normally left in the OFF position.
+
+
+*****************************************************************************
+
+** Topware **
+8-bit card, TA-ARC/10
+-------------------------
+  - from Vojtech Pavlik <Vojtech.Pavlik@st.mff.cuni.cz>
+
+This is another very similar 90C65 card. Most of the switches and jumpers
+are the same as on other clones.
+
+ _____________________________________________________________________
+|  ___________   |                         |            ______        |
+| |SW2 NODE ID|  |                         |           | XTAL |       |
+| |___________|  |  Hybrid IC              |           |______|       |
+|  ___________   |                         |                        __|    
+| |SW1 MEM+I/O|  |_________________________|                   LED1|__|)   
+| |___________|           1 2                                         |     
+|                     J3 |o|o| TIMEOUT                          ______|    
+|     ______________     |o|o|                                 |      |    
+|    |              |  ___________________                     | RJ   |    
+|    > EPROM SOCKET | |                   \                    |------|     
+|J2  |______________| |                    |                   |      |    
+||o|                  |                    |                   |______|
+||o| ROM ENABLE       |        SMC         |    _________             |
+|     _____________   |       90C65        |   |_________|       _____|    
+|    |             |  |                    |                    |     |___ 
+|    > RAM (2k)    |  |                    |                    | BNC |___|
+|    |_____________|  |                    |                    |_____|    
+|                     |____________________|                          |    
+| ________ IRQ 2 3 4 5 7                  ___________                 |
+||________|   |o|o|o|o|o|                |___________|                |
+|________   J1|o|o|o|o|o|                               ______________|
+         |                                             |
+         |_____________________________________________|
+
+Legend:
+
+90C65       ARCNET Chip
+XTAL        20 MHz Crystal
+SW1 1-5     Base Memory Address Select
+    6-8     Base I/O Address Select
+SW2 1-8     Node ID Select (ID0-ID7)
+J1          IRQ Select
+J2          Rom Enable
+J3          Extra Timeout
+LED1        Activity LED 
+BNC         Coax connector (BUS arcnet)
+RJ          Twisted Pair Connector (daisychain)
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in SW2 are used to set the node ID. Each node attached to
+the network must have an unique node ID which must not be 0.  Switch 1 (ID0)
+serves as the least significant bit (LSB).
+
+Setting one of the switches to Off means "1", On means "0".
+
+The node ID is the sum of the values of all switches set to "1"
+These values are:
+
+   Switch | Label | Value
+   -------|-------|-------
+     1    | ID0   |   1
+     2    | ID1   |   2
+     3    | ID2   |   4
+     4    | ID3   |   8
+     5    | ID4   |  16
+     6    | ID5   |  32
+     7    | ID6   |  64
+     8    | ID7   | 128
+
+Setting the I/O Base Address
+----------------------------
+
+The last three switches in switch block SW1 are used to select one
+of eight possible I/O Base addresses using the following table:
+
+
+   Switch      | Hex I/O
+    6   7   8  | Address
+   ------------|--------
+   ON  ON  ON  |  260  (Manufacturer's default)
+   OFF ON  ON  |  290
+   ON  OFF ON  |  2E0                         
+   OFF OFF ON  |  2F0
+   ON  ON  OFF |  300
+   OFF ON  OFF |  350
+   ON  OFF OFF |  380
+   OFF OFF OFF |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer (RAM) requires 2K. The base of this buffer can be
+located in any of eight positions. The address of the Boot Prom is
+memory base + 0x2000.
+Jumpers 3-5 of switch block SW1 select the Memory Base address.
+
+   Switch              | Hex RAM | Hex ROM
+    1   2   3   4   5  | Address | Address *)
+   --------------------|---------|-----------
+   ON  ON  ON  ON  ON  |  C0000  |  C2000
+   ON  ON  OFF ON  ON  |  C4000  |  C6000  (Manufacturer's default) 
+   ON  ON  ON  OFF ON  |  CC000  |  CE000
+   ON  ON  OFF OFF ON  |  D0000  |  D2000  
+   ON  ON  ON  ON  OFF |  D4000  |  D6000
+   ON  ON  OFF ON  OFF |  D8000  |  DA000
+   ON  ON  ON  OFF OFF |  DC000  |  DE000
+   ON  ON  OFF OFF OFF |  E0000  |  E2000
+
+*) To enable the Boot ROM short the jumper J2.
+
+The jumpers 1 and 2 probably add 0x0800 and 0x1000 to RAM address.
+
+
+Setting the Interrupt Line
+--------------------------
+
+Jumpers 1-5 of the jumper block J1 control the IRQ level.  ON means
+shorted, OFF means open.
+
+    Jumper              |  IRQ
+    1   2   3   4   5   |
+   ----------------------------
+    ON  OFF OFF OFF OFF |  2
+    OFF ON  OFF OFF OFF |  3
+    OFF OFF ON  OFF OFF |  4
+    OFF OFF OFF ON  OFF |  5
+    OFF OFF OFF OFF ON  |  7
+
+
+Setting the Timeout Parameters
+------------------------------
+
+The jumpers J3 are used to set the timeout parameters. These two 
+jumpers are normally left open.
+
+  
+*****************************************************************************
+
+** Thomas-Conrad **
+Model #500-6242-0097 REV A (8-bit card)
+---------------------------------------
+  - from Lars Karlsson <100617.3473@compuserve.com>
+
+     ________________________________________________________
+   |          ________   ________                           |_____
+   |         |........| |........|                            |
+   |         |________| |________|                         ___|
+   |            SW 3       SW 1                           |   |
+   |         Base I/O   Base Addr.                Station |   |
+   |                                              address |   |
+   |    ______                                    switch  |   |
+   |   |      |                                           |   |
+   |   |      |                                           |___|    
+   |   |      |                                 ______        |___._
+   |   |______|                                |______|         ____| BNC
+   |                                            Jumper-        _____| Connector
+   |   Main chip                                block  _    __|   '  
+   |                                                  | |  |    RJ Connector
+   |                                                  |_|  |    with 110 Ohm
+   |                                                       |__  Terminator
+   |    ___________                                         __|
+   |   |...........|                                       |    RJ-jack
+   |   |...........|    _____                              |    (unused)
+   |   |___________|   |_____|                             |__
+   |  Boot PROM socket IRQ-jumpers                            |_  Diagnostic
+   |________                                       __          _| LED (red)
+            | | | | | | | | | | | | | | | | | | | |  |        |
+            | | | | | | | | | | | | | | | | | | | |  |________|
+                                                              |
+                                                              |
+
+And here are the settings for some of the switches and jumpers on the cards.
+
+
+          I/O
+
+         1 2 3 4 5 6 7 8
+
+2E0----- 0 0 0 1 0 0 0 1
+2F0----- 0 0 0 1 0 0 0 0
+300----- 0 0 0 0 1 1 1 1
+350----- 0 0 0 0 1 1 1 0
+
+"0" in the above example means switch is off "1" means that it is on.
+
+
+    ShMem address.
+
+      1 2 3 4 5 6 7 8
+
+CX00--0 0 1 1 | |   |
+DX00--0 0 1 0       |
+X000--------- 1 1   |
+X400--------- 1 0   |
+X800--------- 0 1   |
+XC00--------- 0 0   
+ENHANCED----------- 1
+COMPATIBLE--------- 0
+
+
+       IRQ
+
+
+   3 4 5 7 2
+   . . . . .
+   . . . . .
+
+
+There is a DIP-switch with 8 switches, used to set the shared memory address
+to be used. The first 6 switches set the address, the 7th doesn't have any
+function, and the 8th switch is used to select "compatible" or "enhanced".
+When I got my two cards, one of them had this switch set to "enhanced". That
+card didn't work at all, it wasn't even recognized by the driver. The other
+card had this switch set to "compatible" and it behaved absolutely normally. I
+guess that the switch on one of the cards, must have been changed accidently
+when the card was taken out of its former host. The question remains
+unanswered, what is the purpose of the "enhanced" position?
+
+[Avery's note: "enhanced" probably either disables shared memory (use IO
+ports instead) or disables IO ports (use memory addresses instead).  This
+varies by the type of card involved.  I fail to see how either of these
+enhance anything.  Send me more detailed information about this mode, or
+just use "compatible" mode instead.]
+
+
+*****************************************************************************
+
+** Waterloo Microsystems Inc. ?? **
+8-bit card (C) 1985
+-------------------
+  - from Robert Michael Best <rmb117@cs.usask.ca>
+
+[Avery's note: these don't work with my driver for some reason.  These cards
+SEEM to have settings similar to the PDI508Plus, which is
+software-configured and doesn't work with my driver either.  The "Waterloo
+chip" is a boot PROM, probably designed specifically for the University of
+Waterloo.  If you have any further information about this card, please
+e-mail me.]
+
+The probe has not been able to detect the card on any of the J2 settings,
+and I tried them again with the "Waterloo" chip removed.
+ 
+ _____________________________________________________________________
+| \/  \/              ___  __ __                                      |
+| C4  C4     |^|     | M ||  ^  ||^|                                  |
+| --  --     |_|     | 5 ||     || | C3                               |
+| \/  \/      C10    |___||     ||_|                                  | 
+| C4  C4             _  _ |     |                 ??                  | 
+| --  --            | \/ ||     |                                     | 
+|                   |    ||     |                                     | 
+|                   |    ||  C1 |                                     | 
+|                   |    ||     |  \/                            _____|    
+|                   | C6 ||     |  C9                           |     |___ 
+|                   |    ||     |  --                           | BNC |___| 
+|                   |    ||     |          >C7|                 |_____|
+|                   |    ||     |                                     |
+| __ __             |____||_____|       1 2 3     6                   |
+||  ^  |     >C4|                      |o|o|o|o|o|o| J2    >C4|       |
+||     |                               |o|o|o|o|o|o|                  |
+|| C2  |     >C4|                                          >C4|       |
+||     |                                   >C8|                       |
+||     |       2 3 4 5 6 7  IRQ                            >C4|       |
+||_____|      |o|o|o|o|o|o| J3                                        |
+|_______      |o|o|o|o|o|o|                            _______________|
+        |                                             |
+        |_____________________________________________|
+
+C1 -- "COM9026
+       SMC 8638"
+      In a chip socket.
+
+C2 -- "@Copyright
+       Waterloo Microsystems Inc.
+       1985"
+      In a chip Socket with info printed on a label covering a round window
+      showing the circuit inside. (The window indicates it is an EPROM chip.)
+
+C3 -- "COM9032
+       SMC 8643"
+      In a chip socket.
+
+C4 -- "74LS"
+      9 total no sockets.
+
+M5 -- "50006-136
+       20.000000 MHZ
+       MTQ-T1-S3
+       0 M-TRON 86-40"
+      Metallic case with 4 pins, no socket.
+
+C6 -- "MOSTEK@TC8643
+       MK6116N-20
+       MALAYSIA"
+      No socket.
+
+C7 -- No stamp or label but in a 20 pin chip socket.
+
+C8 -- "PAL10L8CN
+       8623"
+      In a 20 pin socket.
+
+C9 -- "PAl16R4A-2CN
+       8641"
+      In a 20 pin socket.
+
+C10 -- "M8640
+          NMC
+        9306N"
+       In an 8 pin socket.
+
+?? -- Some components on a smaller board and attached with 20 pins all 
+      along the side closest to the BNC connector.  The are coated in a dark 
+      resin.
+
+On the board there are two jumper banks labeled J2 and J3. The 
+manufacturer didn't put a J1 on the board. The two boards I have both 
+came with a jumper box for each bank.
+
+J2 -- Numbered 1 2 3 4 5 6. 
+      4 and 5 are not stamped due to solder points.
+       
+J3 -- IRQ 2 3 4 5 6 7
+
+The board itself has a maple leaf stamped just above the irq jumpers 
+and "-2 46-86" beside C2. Between C1 and C6 "ASS 'Y 300163" and "@1986 
+CORMAN CUSTOM ELECTRONICS CORP." stamped just below the BNC connector.
+Below that "MADE IN CANADA"
+
+  
+*****************************************************************************
+
+** No Name **
+8-bit cards, 16-bit cards
+-------------------------
+  - from Juergen Seifert <seifert@htwm.de>
+  
+NONAME 8-BIT ARCNET
+===================
+
+I have named this ARCnet card "NONAME", since there is no name of any
+manufacturer on the Installation manual nor on the shipping box. The only
+hint to the existence of a manufacturer at all is written in copper,
+it is "Made in Taiwan"
+
+This description has been written by Juergen Seifert <seifert@htwm.de>
+using information from the Original
+                    "ARCnet Installation Manual"
+
+
+    ________________________________________________________________
+   | |STAR| BUS| T/P|                                               |
+   | |____|____|____|                                               |
+   |                            _____________________               |
+   |                           |                     |              |
+   |                           |                     |              |
+   |                           |                     |              |
+   |                           |        SMC          |              |
+   |                           |                     |              |
+   |                           |       COM90C65      |              |
+   |                           |                     |              |
+   |                           |                     |              |
+   |                           |__________-__________|              |
+   |                                                           _____|
+   |      _______________                                     |  CN |
+   |     | PROM          |                                    |_____|
+   |     > SOCKET        |                                          |
+   |     |_______________|         1 2 3 4 5 6 7 8  1 2 3 4 5 6 7 8 |
+   |                               _______________  _______________ |
+   |           |o|o|o|o|o|o|o|o|  |      SW1      ||      SW2      ||
+   |           |o|o|o|o|o|o|o|o|  |_______________||_______________||
+   |___         2 3 4 5 7 E E R        Node ID       IOB__|__MEM____|
+       |        \ IRQ   / T T O                      |
+       |__________________1_2_M______________________|
+
+Legend:
+
+COM90C65:       Arcnet Probe
+S1  1-8:    Node ID Select
+S2  1-3:    I/O Base Address Select
+    4-6:    Memory Base Address Select
+    7-8:    RAM Offset Select
+ET1, ET2    Extended Timeout Select
+ROM     ROM Enable Select
+CN              RG62 Coax Connector
+STAR| BUS | T/P Three fields for placing a sign (colored circle)
+                indicating the topology of the card
+
+Setting one of the switches to Off means "1", On means "0".
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in group SW1 are used to set the node ID.
+Each node attached to the network must have an unique node ID which
+must be different from 0.
+Switch 8 serves as the least significant bit (LSB).
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+    Switch | Value
+    -------|-------
+      8    |   1
+      7    |   2
+      6    |   4
+      5    |   8
+      4    |  16
+      3    |  32
+      2    |  64
+      1    | 128
+
+Some Examples:
+
+    Switch         | Hex     | Decimal 
+   1 2 3 4 5 6 7 8 | Node ID | Node ID
+   ----------------|---------|---------
+   0 0 0 0 0 0 0 0 |    not allowed
+   0 0 0 0 0 0 0 1 |    1    |    1 
+   0 0 0 0 0 0 1 0 |    2    |    2
+   0 0 0 0 0 0 1 1 |    3    |    3
+       . . .       |         |
+   0 1 0 1 0 1 0 1 |   55    |   85
+       . . .       |         |
+   1 0 1 0 1 0 1 0 |   AA    |  170
+       . . .       |         |  
+   1 1 1 1 1 1 0 1 |   FD    |  253
+   1 1 1 1 1 1 1 0 |   FE    |  254
+   1 1 1 1 1 1 1 1 |   FF    |  255
+
+
+Setting the I/O Base Address
+----------------------------
+
+The first three switches in switch group SW2 are used to select one
+of eight possible I/O Base addresses using the following table
+
+   Switch      | Hex I/O
+    1   2   3  | Address
+   ------------|--------
+   ON  ON  ON  |  260
+   ON  ON  OFF |  290
+   ON  OFF ON  |  2E0  (Manufacturer's default)
+   ON  OFF OFF |  2F0
+   OFF ON  ON  |  300
+   OFF ON  OFF |  350
+   OFF OFF ON  |  380
+   OFF OFF OFF |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer requires 2K of a 16K block of RAM. The base of this
+16K block can be located in any of eight positions.
+Switches 4-6 of switch group SW2 select the Base of the 16K block.
+Within that 16K address space, the buffer may be assigned any one of four
+positions, determined by the offset, switches 7 and 8 of group SW2.
+
+   Switch     | Hex RAM | Hex ROM
+   4 5 6  7 8 | Address | Address *)
+   -----------|---------|-----------
+   0 0 0  0 0 |  C0000  |  C2000
+   0 0 0  0 1 |  C0800  |  C2000
+   0 0 0  1 0 |  C1000  |  C2000
+   0 0 0  1 1 |  C1800  |  C2000
+              |         |
+   0 0 1  0 0 |  C4000  |  C6000
+   0 0 1  0 1 |  C4800  |  C6000
+   0 0 1  1 0 |  C5000  |  C6000
+   0 0 1  1 1 |  C5800  |  C6000
+              |         |
+   0 1 0  0 0 |  CC000  |  CE000
+   0 1 0  0 1 |  CC800  |  CE000
+   0 1 0  1 0 |  CD000  |  CE000
+   0 1 0  1 1 |  CD800  |  CE000
+              |         |
+   0 1 1  0 0 |  D0000  |  D2000  (Manufacturer's default)
+   0 1 1  0 1 |  D0800  |  D2000
+   0 1 1  1 0 |  D1000  |  D2000
+   0 1 1  1 1 |  D1800  |  D2000
+              |         |
+   1 0 0  0 0 |  D4000  |  D6000
+   1 0 0  0 1 |  D4800  |  D6000
+   1 0 0  1 0 |  D5000  |  D6000
+   1 0 0  1 1 |  D5800  |  D6000
+              |         |
+   1 0 1  0 0 |  D8000  |  DA000
+   1 0 1  0 1 |  D8800  |  DA000
+   1 0 1  1 0 |  D9000  |  DA000
+   1 0 1  1 1 |  D9800  |  DA000
+              |         |
+   1 1 0  0 0 |  DC000  |  DE000
+   1 1 0  0 1 |  DC800  |  DE000
+   1 1 0  1 0 |  DD000  |  DE000
+   1 1 0  1 1 |  DD800  |  DE000
+              |         |
+   1 1 1  0 0 |  E0000  |  E2000
+   1 1 1  0 1 |  E0800  |  E2000
+   1 1 1  1 0 |  E1000  |  E2000
+   1 1 1  1 1 |  E1800  |  E2000
+  
+*) To enable the 8K Boot PROM install the jumper ROM.
+   The default is jumper ROM not installed.
+
+
+Setting Interrupt Request Lines (IRQ)
+-------------------------------------
+
+To select a hardware interrupt level set one (only one!) of the jumpers
+IRQ2, IRQ3, IRQ4, IRQ5 or IRQ7. The manufacturer's default is IRQ2.
+ 
+
+Setting the Timeouts
+--------------------
+
+The two jumpers labeled ET1 and ET2 are used to determine the timeout
+parameters (respons and reconfiguration time). Every node in a network
+must be set to the same timeout values.
+
+   ET1 ET2 | Response Time (us) | Reconfiguration Time (ms)
+   --------|--------------------|--------------------------
+   Off Off |        78          |          840   (Default)
+   Off On  |       285          |         1680
+   On  Off |       563          |         1680
+   On  On  |      1130          |         1680
+
+On means jumper installed, Off means jumper not installed
+
+
+NONAME 16-BIT ARCNET
+====================
+
+The manual of my 8-Bit NONAME ARCnet Card contains another description
+of a 16-Bit Coax / Twisted Pair Card. This description is incomplete,
+because there are missing two pages in the manual booklet. (The table
+of contents reports pages ... 2-9, 2-11, 2-12, 3-1, ... but inside
+the booklet there is a different way of counting ... 2-9, 2-10, A-1,
+(empty page), 3-1, ..., 3-18, A-1 (again), A-2)
+Also the picture of the board layout is not as good as the picture of
+8-Bit card, because there isn't any letter like "SW1" written to the
+picture.
+Should somebody have such a board, please feel free to complete this
+description or to send a mail to me!
+
+This description has been written by Juergen Seifert <seifert@htwm.de>
+using information from the Original
+                    "ARCnet Installation Manual"
+
+
+   ___________________________________________________________________
+  <                    _________________  _________________           |
+  >                   |       SW?       ||      SW?        |          |
+  <                   |_________________||_________________|          |
+  >                       ____________________                        |
+  <                      |                    |                       |
+  >                      |                    |                       |
+  <                      |                    |                       |
+  >                      |                    |                       |
+  <                      |                    |                       |
+  >                      |                    |                       |
+  <                      |                    |                       |
+  >                      |____________________|                       |
+  <                                                               ____|
+  >                       ____________________                   |    |
+  <                      |                    |                  | J1 |
+  >                      |                    <                  |    |
+  <                      |____________________|  ? ? ? ? ? ?     |____|
+  >                                             |o|o|o|o|o|o|         |
+  <                                             |o|o|o|o|o|o|         |
+  >                                                                   |
+  <             __                                         ___________|
+  >            |  |                                       |
+  <____________|  |_______________________________________|
+
+
+Setting one of the switches to Off means "1", On means "0".
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in group SW2 are used to set the node ID.
+Each node attached to the network must have an unique node ID which
+must be different from 0.
+Switch 8 serves as the least significant bit (LSB).
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+    Switch | Value
+    -------|-------
+      8    |   1
+      7    |   2
+      6    |   4
+      5    |   8
+      4    |  16
+      3    |  32
+      2    |  64
+      1    | 128
+
+Some Examples:
+
+    Switch         | Hex     | Decimal 
+   1 2 3 4 5 6 7 8 | Node ID | Node ID
+   ----------------|---------|---------
+   0 0 0 0 0 0 0 0 |    not allowed
+   0 0 0 0 0 0 0 1 |    1    |    1 
+   0 0 0 0 0 0 1 0 |    2    |    2
+   0 0 0 0 0 0 1 1 |    3    |    3
+       . . .       |         |
+   0 1 0 1 0 1 0 1 |   55    |   85
+       . . .       |         |
+   1 0 1 0 1 0 1 0 |   AA    |  170
+       . . .       |         |  
+   1 1 1 1 1 1 0 1 |   FD    |  253
+   1 1 1 1 1 1 1 0 |   FE    |  254
+   1 1 1 1 1 1 1 1 |   FF    |  255
+
+
+Setting the I/O Base Address
+----------------------------
+
+The first three switches in switch group SW1 are used to select one
+of eight possible I/O Base addresses using the following table
+
+   Switch      | Hex I/O
+    3   2   1  | Address
+   ------------|--------
+   ON  ON  ON  |  260
+   ON  ON  OFF |  290
+   ON  OFF ON  |  2E0  (Manufacturer's default)
+   ON  OFF OFF |  2F0
+   OFF ON  ON  |  300
+   OFF ON  OFF |  350
+   OFF OFF ON  |  380
+   OFF OFF OFF |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer requires 2K of a 16K block of RAM. The base of this
+16K block can be located in any of eight positions.
+Switches 6-8 of switch group SW1 select the Base of the 16K block.
+Within that 16K address space, the buffer may be assigned any one of four
+positions, determined by the offset, switches 4 and 5 of group SW1.
+
+   Switch     | Hex RAM | Hex ROM
+   8 7 6  5 4 | Address | Address
+   -----------|---------|-----------
+   0 0 0  0 0 |  C0000  |  C2000
+   0 0 0  0 1 |  C0800  |  C2000
+   0 0 0  1 0 |  C1000  |  C2000
+   0 0 0  1 1 |  C1800  |  C2000
+              |         |
+   0 0 1  0 0 |  C4000  |  C6000
+   0 0 1  0 1 |  C4800  |  C6000
+   0 0 1  1 0 |  C5000  |  C6000
+   0 0 1  1 1 |  C5800  |  C6000
+              |         |
+   0 1 0  0 0 |  CC000  |  CE000
+   0 1 0  0 1 |  CC800  |  CE000
+   0 1 0  1 0 |  CD000  |  CE000
+   0 1 0  1 1 |  CD800  |  CE000
+              |         |
+   0 1 1  0 0 |  D0000  |  D2000  (Manufacturer's default)
+   0 1 1  0 1 |  D0800  |  D2000
+   0 1 1  1 0 |  D1000  |  D2000
+   0 1 1  1 1 |  D1800  |  D2000
+              |         |
+   1 0 0  0 0 |  D4000  |  D6000
+   1 0 0  0 1 |  D4800  |  D6000
+   1 0 0  1 0 |  D5000  |  D6000
+   1 0 0  1 1 |  D5800  |  D6000
+              |         |
+   1 0 1  0 0 |  D8000  |  DA000
+   1 0 1  0 1 |  D8800  |  DA000
+   1 0 1  1 0 |  D9000  |  DA000
+   1 0 1  1 1 |  D9800  |  DA000
+              |         |
+   1 1 0  0 0 |  DC000  |  DE000
+   1 1 0  0 1 |  DC800  |  DE000
+   1 1 0  1 0 |  DD000  |  DE000
+   1 1 0  1 1 |  DD800  |  DE000
+              |         |
+   1 1 1  0 0 |  E0000  |  E2000
+   1 1 1  0 1 |  E0800  |  E2000
+   1 1 1  1 0 |  E1000  |  E2000
+   1 1 1  1 1 |  E1800  |  E2000
+  
+
+Setting Interrupt Request Lines (IRQ)
+-------------------------------------
+
+??????????????????????????????????????
+
+
+Setting the Timeouts
+--------------------
+
+??????????????????????????????????????
+
+
+*****************************************************************************
+
+** No Name **
+8-bit cards ("Made in Taiwan R.O.C.")
+-----------
+  - from Vojtech Pavlik <Vojtech.Pavlik@st.mff.cuni.cz>
+
+I have named this ARCnet card "NONAME", since I got only the card with
+no manual at all and the only text identifying the manufacturer is 
+"MADE IN TAIWAN R.O.C" printed on the card.
+
+          ____________________________________________________________
+         |                 1 2 3 4 5 6 7 8                            |
+         | |o|o| JP1       o|o|o|o|o|o|o|o| ON                        |
+         |  +              o|o|o|o|o|o|o|o|                        ___|
+         |  _____________  o|o|o|o|o|o|o|o| OFF         _____     |   | ID7
+         | |             | SW1                         |     |    |   | ID6
+         | > RAM (2k)    |        ____________________ |  H  |    | S | ID5
+         | |_____________|       |                    ||  y  |    | W | ID4
+         |                       |                    ||  b  |    | 2 | ID3
+         |                       |                    ||  r  |    |   | ID2
+         |                       |                    ||  i  |    |   | ID1
+         |                       |       90C65        ||  d  |    |___| ID0
+         |      SW3              |                    ||     |        |      
+         | |o|o|o|o|o|o|o|o| ON  |                    ||  I  |        |
+         | |o|o|o|o|o|o|o|o|     |                    ||  C  |        |
+         | |o|o|o|o|o|o|o|o| OFF |____________________||     |   _____|
+         |  1 2 3 4 5 6 7 8                            |     |  |     |___
+         |  ______________                             |     |  | BNC |___|
+         | |              |                            |_____|  |_____|
+         | > EPROM SOCKET |                                           |
+         | |______________|                                           |
+         |                                              ______________|
+         |                                             |
+         |_____________________________________________|
+
+Legend:
+
+90C65       ARCNET Chip 
+SW1 1-5:    Base Memory Address Select
+    6-8:    Base I/O Address Select
+SW2 1-8:    Node ID Select (ID0-ID7)
+SW3 1-5:    IRQ Select   
+    6-7:    Extra Timeout
+    8  :    Rom Enable   
+JP1         Led connector
+BNC         Coax connector
+
+Although the jumpers SW1 and SW3 are marked SW, not JP, they are jumpers, not 
+switches.
+
+Setting the jumpers to ON means connecting the upper two pins, off the bottom 
+two - or - in case of IRQ setting, connecting none of them at all.
+
+Setting the Node ID
+-------------------
+
+The eight switches in SW2 are used to set the node ID. Each node attached
+to the network must have an unique node ID which must not be 0.
+Switch 1 (ID0) serves as the least significant bit (LSB).
+
+Setting one of the switches to Off means "1", On means "0".
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+   Switch | Label | Value
+   -------|-------|-------
+     1    | ID0   |   1
+     2    | ID1   |   2
+     3    | ID2   |   4
+     4    | ID3   |   8
+     5    | ID4   |  16
+     6    | ID5   |  32
+     7    | ID6   |  64
+     8    | ID7   | 128
+
+Some Examples:
+
+    Switch         | Hex     | Decimal 
+   8 7 6 5 4 3 2 1 | Node ID | Node ID
+   ----------------|---------|---------
+   0 0 0 0 0 0 0 0 |    not allowed
+   0 0 0 0 0 0 0 1 |    1    |    1 
+   0 0 0 0 0 0 1 0 |    2    |    2
+   0 0 0 0 0 0 1 1 |    3    |    3
+       . . .       |         |
+   0 1 0 1 0 1 0 1 |   55    |   85
+       . . .       |         |
+   1 0 1 0 1 0 1 0 |   AA    |  170
+       . . .       |         |  
+   1 1 1 1 1 1 0 1 |   FD    |  253
+   1 1 1 1 1 1 1 0 |   FE    |  254
+   1 1 1 1 1 1 1 1 |   FF    |  255
+
+
+Setting the I/O Base Address
+----------------------------
+
+The last three switches in switch block SW1 are used to select one
+of eight possible I/O Base addresses using the following table
+
+
+   Switch      | Hex I/O
+    6   7   8  | Address
+   ------------|--------
+   ON  ON  ON  |  260
+   OFF ON  ON  |  290
+   ON  OFF ON  |  2E0  (Manufacturer's default)
+   OFF OFF ON  |  2F0
+   ON  ON  OFF |  300
+   OFF ON  OFF |  350
+   ON  OFF OFF |  380
+   OFF OFF OFF |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer (RAM) requires 2K. The base of this buffer can be 
+located in any of eight positions. The address of the Boot Prom is
+memory base + 0x2000.
+Jumpers 3-5 of jumper block SW1 select the Memory Base address.
+
+   Switch              | Hex RAM | Hex ROM
+    1   2   3   4   5  | Address | Address *)
+   --------------------|---------|-----------
+   ON  ON  ON  ON  ON  |  C0000  |  C2000
+   ON  ON  OFF ON  ON  |  C4000  |  C6000
+   ON  ON  ON  OFF ON  |  CC000  |  CE000
+   ON  ON  OFF OFF ON  |  D0000  |  D2000  (Manufacturer's default)
+   ON  ON  ON  ON  OFF |  D4000  |  D6000
+   ON  ON  OFF ON  OFF |  D8000  |  DA000
+   ON  ON  ON  OFF OFF |  DC000  |  DE000
+   ON  ON  OFF OFF OFF |  E0000  |  E2000
+  
+*) To enable the Boot ROM set the jumper 8 of jumper block SW3 to position ON.
+
+The jumpers 1 and 2 probably add 0x0800, 0x1000 and 0x1800 to RAM adders.
+
+Setting the Interrupt Line
+--------------------------
+
+Jumpers 1-5 of the jumper block SW3 control the IRQ level.
+
+    Jumper              |  IRQ
+    1   2   3   4   5   |
+   ----------------------------
+    ON  OFF OFF OFF OFF |  2
+    OFF ON  OFF OFF OFF |  3
+    OFF OFF ON  OFF OFF |  4
+    OFF OFF OFF ON  OFF |  5
+    OFF OFF OFF OFF ON  |  7
+
+
+Setting the Timeout Parameters
+------------------------------
+
+The jumpers 6-7 of the jumper block SW3 are used to determine the timeout 
+parameters. These two jumpers are normally left in the OFF position.
+
+
+*****************************************************************************
+
+** No Name **
+(Generic Model 9058)
+--------------------
+  - from Andrew J. Kroll <ag784@freenet.buffalo.edu>
+  - Sorry this sat in my to-do box for so long, Andrew! (yikes - over a
+    year!)
+                                                                      _____
+                                                                     |    <
+                                                                     | .---'
+    ________________________________________________________________ | |
+   |                           |     SW2     |                      |  |
+   |   ___________             |_____________|                      |  |
+   |  |           |              1 2 3 4 5 6                     ___|  |
+   |  >  6116 RAM |         _________                         8 |   |  |
+   |  |___________|        |20MHzXtal|                        7 |   |  |
+   |                       |_________|       __________       6 | S |  |
+   |    74LS373                             |          |-     5 | W |  |
+   |   _________                            |      E   |-     4 |   |  |
+   |   >_______|              ______________|..... P   |-     3 | 3 |  |
+   |                         |              |    : O   |-     2 |   |  |
+   |                         |              |    : X   |-     1 |___|  |
+   |   ________________      |              |    : Y   |-           |  |
+   |  |      SW1       |     |      SL90C65 |    :     |-           |  |
+   |  |________________|     |              |    : B   |-           |  |
+   |    1 2 3 4 5 6 7 8      |              |    : O   |-           |  |
+   |                         |_________o____|..../ A   |-    _______|  |
+   |    ____________________                |      R   |-   |       |------,   
+   |   |                    |               |      D   |-   |  BNC  |   #  |
+   |   > 2764 PROM SOCKET   |               |__________|-   |_______|------'
+   |   |____________________|              _________                |  |
+   |                                       >________| <- 74LS245    |  |
+   |                                                                |  |
+   |___                                               ______________|  |
+       |H H H H H H H H H H H H H H H H H H H H H H H|               | |
+       |U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U|               | |
+                                                                      \|
+Legend:
+
+SL90C65 	ARCNET Controller / Transceiver /Logic
+SW1	1-5:	IRQ Select
+	  6:	ET1
+	  7:	ET2
+	  8:	ROM ENABLE 
+SW2	1-3:    Memory Buffer/PROM Address
+	3-6:	I/O Address Map
+SW3	1-8:	Node ID Select
+BNC		BNC RG62/U Connection 
+		*I* have had success using RG59B/U with *NO* terminators!
+		What gives?!
+
+SW1: Timeouts, Interrupt and ROM
+---------------------------------
+
+To select a hardware interrupt level set one (only one!) of the dip switches
+up (on) SW1...(switches 1-5)
+IRQ3, IRQ4, IRQ5, IRQ7, IRQ2. The Manufacturer's default is IRQ2.
+
+The switches on SW1 labeled EXT1 (switch 6) and EXT2 (switch 7)
+are used to determine the timeout parameters. These two dip switches
+are normally left off (down).
+
+   To enable the 8K Boot PROM position SW1 switch 8 on (UP) labeled ROM.
+   The default is jumper ROM not installed.
+
+
+Setting the I/O Base Address
+----------------------------
+
+The last three switches in switch group SW2 are used to select one
+of eight possible I/O Base addresses using the following table
+
+
+   Switch | Hex I/O
+   4 5 6  | Address
+   -------|--------
+   0 0 0  |  260
+   0 0 1  |  290
+   0 1 0  |  2E0  (Manufacturer's default)
+   0 1 1  |  2F0
+   1 0 0  |  300
+   1 0 1  |  350
+   1 1 0  |  380
+   1 1 1  |  3E0
+
+
+Setting the Base Memory Address (RAM & ROM)
+-------------------------------------------
+
+The memory buffer requires 2K of a 16K block of RAM. The base of this
+16K block can be located in any of eight positions.
+Switches 1-3 of switch group SW2 select the Base of the 16K block.
+(0 = DOWN, 1 = UP)
+I could, however, only verify two settings...
+
+   Switch| Hex RAM | Hex ROM
+   1 2 3 | Address | Address
+   ------|---------|-----------
+   0 0 0 |  E0000  |  E2000
+   0 0 1 |  D0000  |  D2000  (Manufacturer's default)
+   0 1 0 |  ?????  |  ?????
+   0 1 1 |  ?????  |  ?????  
+   1 0 0 |  ?????  |  ?????
+   1 0 1 |  ?????  |  ?????
+   1 1 0 |  ?????  |  ?????
+   1 1 1 |  ?????  |  ?????
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in group SW3 are used to set the node ID.
+Each node attached to the network must have an unique node ID which
+must be different from 0.
+Switch 1 serves as the least significant bit (LSB).
+switches in the DOWN position are OFF (0) and in the UP position are ON (1)
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+    Switch | Value
+    -------|-------
+      1    |   1
+      2    |   2
+      3    |   4
+      4    |   8
+      5    |  16
+      6    |  32
+      7    |  64
+      8    | 128
+
+Some Examples:
+
+    Switch#     |   Hex   | Decimal 
+8 7 6 5 4 3 2 1 | Node ID | Node ID
+----------------|---------|---------
+0 0 0 0 0 0 0 0 |    not allowed  <-.
+0 0 0 0 0 0 0 1 |    1    |    1    | 
+0 0 0 0 0 0 1 0 |    2    |    2    |
+0 0 0 0 0 0 1 1 |    3    |    3    |
+    . . .       |         |         |
+0 1 0 1 0 1 0 1 |   55    |   85    |
+    . . .       |         |         + Don't use 0 or 255!
+1 0 1 0 1 0 1 0 |   AA    |  170    |
+    . . .       |         |         |
+1 1 1 1 1 1 0 1 |   FD    |  253    |
+1 1 1 1 1 1 1 0 |   FE    |  254    |
+1 1 1 1 1 1 1 1 |   FF    |  255  <-'
+  
+
+*****************************************************************************
+
+** Tiara **
+(model unknown)
+-------------------------
+  - from Christoph Lameter <clameter@netcom.com>
+  
+
+Here is information about my card as far as I could figure it out:
+----------------------------------------------- tiara
+Tiara LanCard of Tiara Computer Systems.
+
++----------------------------------------------+
+!           ! Transmitter Unit !               !
+!           +------------------+             -------
+!          MEM                              Coax Connector
+!  ROM    7654321 <- I/O                     -------
+!  :  :   +--------+                           !
+!  :  :   ! 90C66LJ!                         +++
+!  :  :   !        !                         !D  Switch to set
+!  :  :   !        !                         !I  the Nodenumber
+!  :  :   +--------+                         !P
+!                                            !++
+!         234567 <- IRQ                      !
++------------!!!!!!!!!!!!!!!!!!!!!!!!--------+
+             !!!!!!!!!!!!!!!!!!!!!!!!
+
+0 = Jumper Installed
+1 = Open
+
+Top Jumper line Bit 7 = Rom Enable 654=Memory location 321=I/O
+
+Settings for Memory Location (Top Jumper Line)
+456     Address selected
+000	C0000
+001     C4000
+010     CC000
+011     D0000
+100     D4000
+101     D8000
+110     DC000     
+111     E0000
+
+Settings for I/O Address (Top Jumper Line)
+123     Port
+000	260
+001	290
+010	2E0
+011	2F0
+100	300
+101	350
+110	380
+111	3E0
+
+Settings for IRQ Selection (Lower Jumper Line)
+234567
+011111 IRQ 2
+101111 IRQ 3
+110111 IRQ 4
+111011 IRQ 5
+111110 IRQ 7
+
+*****************************************************************************
+
+
+Other Cards
+-----------
+
+I have no information on other models of ARCnet cards at the moment.  Please
+send any and all info to:
+	apenwarr@foxnet.net
+
+Thanks.
diff --git a/Documentation/networking/arcnet.txt b/Documentation/networking/arcnet.txt
new file mode 100644
index 000000000..c0eefc006
--- /dev/null
+++ b/Documentation/networking/arcnet.txt
@@ -0,0 +1,506 @@
+
+----------------------------------------------------------------------------
+NOTE:  See also arcnet-hardware.txt in this directory for jumper-setting
+and cabling information if you're like many of us and didn't happen to get a
+manual with your ARCnet card.
+----------------------------------------------------------------------------
+
+Since no one seems to listen to me otherwise, perhaps a poem will get your
+attention:
+		This driver's getting fat and beefy,
+		But my cat is still named Fifi.
+
+Hmm, I think I'm allowed to call that a poem, even though it's only two
+lines.  Hey, I'm in Computer Science, not English.  Give me a break.
+
+The point is:  I REALLY REALLY REALLY REALLY REALLY want to hear from you if
+you test this and get it working.  Or if you don't.  Or anything.
+
+ARCnet 0.32 ALPHA first made it into the Linux kernel 1.1.80 - this was
+nice, but after that even FEWER people started writing to me because they
+didn't even have to install the patch.  <sigh>
+
+Come on, be a sport!  Send me a success report!
+
+(hey, that was even better than my original poem... this is getting bad!)
+
+
+--------
+WARNING:
+--------
+
+If you don't e-mail me about your success/failure soon, I may be forced to
+start SINGING.  And we don't want that, do we?
+
+(You know, it might be argued that I'm pushing this point a little too much. 
+If you think so, why not flame me in a quick little e-mail?  Please also
+include the type of card(s) you're using, software, size of network, and
+whether it's working or not.)
+
+My e-mail address is: apenwarr@foxnet.net
+
+
+---------------------------------------------------------------------------
+
+			
+These are the ARCnet drivers for Linux.
+
+This new release has resulted from many months of on-and-off effort from me
+(Avery Pennarun), many bug reports/fixes and suggestions from others, and in
+particular a lot of input and coding from Tomasz Motylewski.  Starting with
+ARCnet 2.10 ALPHA, Tomasz's all-new-and-improved RFC1051 support has been
+included and seems to be working fine!
+
+
+Where do I discuss these drivers?
+---------------------------------
+
+Tomasz has been so kind as to set up a new and improved mailing list. 
+Subscribe by sending a message with the BODY "subscribe linux-arcnet YOUR
+REAL NAME" to listserv@tichy.ch.uj.edu.pl.  Then, to submit messages to the
+list, mail to linux-arcnet@tichy.ch.uj.edu.pl.
+
+There are archives of the mailing list at:
+	http://tichy.ch.uj.edu.pl/lists/linux-arcnet
+
+The people on linux-net@vger.rutgers.edu have also been known to be very
+helpful, especially when we're talking about ALPHA Linux kernels that may or
+may not work right in the first place.
+
+
+Other Drivers and Info
+----------------------
+
+You can try my ARCNET page on the World Wide Web at:
+	http://www.foxnet.net/~apenwarr/arcnet/
+
+Also, SMC (one of the companies that makes ARCnet cards) has a WWW site you
+might be interested in, which includes several drivers for various cards
+including ARCnet.  Try:
+	http://www.smc.com/
+	
+Performance Technologies makes various network software that supports
+ARCnet:
+	http://www.perftech.com/ or ftp to ftp.perftech.com.
+	
+Novell makes a networking stack for DOS which includes ARCnet drivers.  Try
+ftp'ing to ftp.novell.com.
+
+You can get the Crynwr packet driver collection (including arcether.com, the
+one you'll want to use with arcnet cards) from
+oak.oakland.edu:/simtel/msdos/pktdrvr. It won't work perfectly on a 386+
+without patches, though, and also doesn't like several cards.  Fixed
+versions are available on my WWW page, or via e-mail if you don't have WWW
+access. 
+
+
+Installing the Driver
+---------------------
+
+** Note: the latest version of the driver contains preliminary support for
+	ARCnet RIM I cards.  These are very old cards that don't use I/O
+	ports at all, but rather map the status and command ports into
+	shared memory.  To compile the driver in RIM I mode, you must (for
+	now) edit linux/drivers/net/arcnet.c, find the line that says:
+		#undef RIM_I_MODE
+	and change it to:
+		#define RIM_I_MODE
+
+All you will need to do in order to install the driver is:
+	make config
+		(be sure to choose ARCnet in the network devices)
+	make dep
+	make clean
+	make zImage
+	
+If you obtained this ARCnet package as an upgrade to the ARCnet driver in
+your current kernel, you will need to first copy arcnet.c over the one in
+the linux/drivers/net directory.
+
+You will know the driver is installed properly if you get some ARCnet
+messages when you reboot into the new Linux kernel.
+
+If you use a RIM I card, you will need to give the kernel boot parameters
+specifying your card's irq, node ID, and shared memory.  For example,
+	LILO boot: linux ether=9,0x42,0xD0000,0,arc0
+if your card is node number 42h, irq 9, with shared memory at 0xD0000.
+
+NOTE that if you aren't using RIM I, the above command will still work but
+you will need to replace the node ID with an I/O port number, for example:
+	LILO boot: linux ether=9,0x300,0xD0000,0,arc0
+
+You can add the ether= parameter to /etc/lilo.conf to avoid typing this
+every time.
+
+
+Loadable Module Support
+-----------------------
+
+Configure and rebuild Linux.  When asked, answer 'm' to "arcnet support" if
+you want to use the loadable module.
+
+	make config
+	make dep
+	make clean	
+	make zImage
+	make modules
+	
+If you're using a loadable module, you need to use insmod to load it, and
+you can specify various characteristics of your card on the command
+line.  (In recent versions of the driver, autoprobing is much more reliable
+and works as a module, so most of this is now unnecessary.)
+
+For example:
+	cd /usr/src/linux/modules
+	insmod arcnet.o io=0x300 irq=2 shmem=0xd0000
+
+You can name the device using something like "device=arc1" (for a second
+card) or "device=eth0" (for weird compatibility reasons) if you like.
+
+If you use RIM I, you don't need to specify io= but you must include node=
+for your ARCnet card's station ID.
+	
+
+Using the Driver
+----------------
+
+If you build your kernel with ARCnet support included, it should probe for
+your card automatically when you boot.
+
+Go read the NET-2-HOWTO and ETHERNET-HOWTO for Linux; they should be
+available where you picked up this driver.  Think of your ARCnet as a
+souped-up (or down, as the case may be) ethernet card.
+
+By the way, be sure to change all references from "eth0" to "arc0" in the
+HOWTOs.  Remember that ARCnet isn't a "true" ethernet, and the device name
+is DIFFERENT.
+
+
+Multiple Cards in One Computer
+------------------------------
+
+Linux has pretty good support for this now, but since I've been busy, the
+ARCnet driver has somewhat suffered in this respect.  For now, the easiest
+way to use multiple ARCnet cards is to build it as a loadable module and
+then do something like this:
+	insmod -o arc0 arcnet
+	insmod -o arc1 arcnet device=arc1
+(Note that in the first line, the default is device=arc0, but it doesn't
+hurt if you want to add it for consistency.)
+
+
+How do I get it to work with...?
+--------------------------------
+
+NFS: Should be fine linux->linux, just pretend you're using ethernet cards. 
+        oak.oakland.edu:/simtel/msdos/nfs has some nice DOS clients.  There
+        is also a DOS-based NFS server called SOSS.  It doesn't multitask
+        quite the way Linux does (actually, it doesn't multitask AT ALL) but
+        you never know what you might need.
+        
+        With AmiTCP (and possibly others), you may need to set the following
+        options in your Amiga nfstab:  MD 1024 MR 1024 MW 1024
+        (Thanks to Christian Gottschling <ferksy@indigo.tng.oche.de>
+	for this.)
+	
+	Probably these refer to maximum NFS data/read/write block sizes.  I
+	don't know why the defaults on the Amiga didn't work; write to me if
+	you know more.
+
+DOS: If you're using the freeware arcether.com, you might want to install
+        the driver patch from my web page.  It helps with PC/TCP, and also
+        can get arcether to load if it timed out too quickly during
+        initialization.  In fact, if you use it on a 386+ you REALLY need
+        the patch, really.
+	
+Windows:  See DOS :)  Trumpet Winsock works fine with either the Novell or
+	Arcether client, assuming you remember to load winpkt of course.
+
+LAN Manager and Windows for Workgroups: These programs use protocols that
+        are incompatible with the internet standard.  They try to pretend
+        the cards are ethernet, and confuse everyone else on the network. 
+        
+        However, v2.00 and higher of the Linux ARCnet driver supports this
+        protocol via the 'arc0e' device.  See the section on "Multiprotocol
+        Support" for more information.
+
+	Using the freeware Samba server and clients for Linux, you can now
+	interface quite nicely with TCP/IP-based WfWg or Lan Manager
+	networks.
+	
+Windows 95: Tools are included with Win95 that let you use either the LANMAN
+	style network drivers (NDIS) or Novell drivers (ODI) to handle your
+	ARCnet packets.  If you use ODI, you'll need to use the 'arc0'
+	device with Linux.  If you use NDIS, then try the 'arc0e' device. 
+	See the "Multiprotocol Support" section below if you need arc0e,
+	you're completely insane, and/or you need to build some kind of
+	hybrid network that uses both encapsulation types.
+
+OS2: I've been told it works under Warp Connect with an ARCnet driver from
+	SMC.  You need to use the 'arc0e' interface for this.  If you get
+	the SMC driver to work with the TCP/IP stuff included in the
+	"normal" Warp Bonus Pack, let me know.
+
+	ftp.microsoft.com also has a freeware "Lan Manager for OS/2" client
+	which should use the same protocol as WfWg does.  I had no luck
+	installing it under Warp, however.  Please mail me with any results.
+
+NetBSD/AmiTCP: These use an old version of the Internet standard ARCnet
+	protocol (RFC1051) which is compatible with the Linux driver v2.10
+	ALPHA and above using the arc0s device. (See "Multiprotocol ARCnet"
+	below.)  ** Newer versions of NetBSD apparently support RFC1201.
+
+
+Using Multiprotocol ARCnet
+--------------------------
+
+The ARCnet driver v2.10 ALPHA supports three protocols, each on its own
+"virtual network device":
+
+	arc0  - RFC1201 protocol, the official internet standard which just
+		happens to be 100% compatible with Novell's TRXNET driver. 
+		Version 1.00 of the ARCnet driver supported _only_ this
+		protocol.  arc0 is the fastest of the three protocols (for
+		whatever reason), and allows larger packets to be used
+		because it supports RFC1201 "packet splitting" operations. 
+		Unless you have a specific need to use a different protocol,
+		I strongly suggest that you stick with this one.
+		
+	arc0e - "Ethernet-Encapsulation" which sends packets over ARCnet
+		that are actually a lot like Ethernet packets, including the
+		6-byte hardware addresses.  This protocol is compatible with
+		Microsoft's NDIS ARCnet driver, like the one in WfWg and
+		LANMAN.  Because the MTU of 493 is actually smaller than the
+		one "required" by TCP/IP (576), there is a chance that some
+		network operations will not function properly.  The Linux
+		TCP/IP layer can compensate in most cases, however, by
+		automatically fragmenting the TCP/IP packets to make them
+		fit.  arc0e also works slightly more slowly than arc0, for
+		reasons yet to be determined.  (Probably it's the smaller
+		MTU that does it.)
+		
+	arc0s - The "[s]imple" RFC1051 protocol is the "previous" internet
+		standard that is completely incompatible with the new
+		standard.  Some software today, however, continues to
+		support the old standard (and only the old standard)
+		including NetBSD and AmiTCP.  RFC1051 also does not support
+		RFC1201's packet splitting, and the MTU of 507 is still
+		smaller than the internet "requirement," so it's quite
+		possible that you may run into problems.  It's also slower
+		than RFC1201 by about 25%, for the same reason as arc0e.
+		
+		The arc0s support was contributed by Tomasz Motylewski
+		and modified somewhat by me.  Bugs are probably my fault.
+
+You can choose not to compile arc0e and arc0s into the driver if you want -
+this will save you a bit of memory and avoid confusion when eg. trying to
+use the "NFS-root" stuff in recent Linux kernels.
+
+The arc0e and arc0s devices are created automatically when you first
+ifconfig the arc0 device.  To actually use them, though, you need to also
+ifconfig the other virtual devices you need.  There are a number of ways you
+can set up your network then:
+
+
+1. Single Protocol.
+
+   This is the simplest way to configure your network: use just one of the
+   two available protocols.  As mentioned above, it's a good idea to use
+   only arc0 unless you have a good reason (like some other software, ie.
+   WfWg, that only works with arc0e).
+   
+   If you need only arc0, then the following commands should get you going:
+   	ifconfig arc0 MY.IP.ADD.RESS
+   	route add MY.IP.ADD.RESS arc0
+   	route add -net SUB.NET.ADD.RESS arc0
+   	[add other local routes here]
+   	
+   If you need arc0e (and only arc0e), it's a little different:
+   	ifconfig arc0 MY.IP.ADD.RESS
+   	ifconfig arc0e MY.IP.ADD.RESS
+   	route add MY.IP.ADD.RESS arc0e
+   	route add -net SUB.NET.ADD.RESS arc0e
+   
+   arc0s works much the same way as arc0e.
+
+
+2. More than one protocol on the same wire.
+
+   Now things start getting confusing.  To even try it, you may need to be
+   partly crazy.  Here's what *I* did. :) Note that I don't include arc0s in
+   my home network; I don't have any NetBSD or AmiTCP computers, so I only
+   use arc0s during limited testing.
+
+   I have three computers on my home network; two Linux boxes (which prefer
+   RFC1201 protocol, for reasons listed above), and one XT that can't run
+   Linux but runs the free Microsoft LANMAN Client instead.
+
+   Worse, one of the Linux computers (freedom) also has a modem and acts as
+   a router to my internet provider.  The other Linux box (insight) also has
+   its own IP address and needs to use freedom as its default gateway.  The
+   XT (patience), however, does not have its own internet IP address and so
+   I assigned it one on a "private subnet" (as defined by RFC1597).
+
+   To start with, take a simple network with just insight and freedom. 
+   Insight needs to:
+   	- talk to freedom via RFC1201 (arc0) protocol, because I like it
+	  more and it's faster.
+	- use freedom as its internet gateway.
+	
+   That's pretty easy to do.  Set up insight like this:
+   	ifconfig arc0 insight
+   	route add insight arc0
+   	route add freedom arc0	/* I would use the subnet here (like I said
+					to to in "single protocol" above),
+   					but the rest of the subnet
+   					unfortunately lies across the PPP
+   					link on freedom, which confuses
+   					things. */
+   	route add default gw freedom
+   	
+   And freedom gets configured like so:
+   	ifconfig arc0 freedom
+   	route add freedom arc0
+   	route add insight arc0
+   	/* and default gateway is configured by pppd */
+   	
+   Great, now insight talks to freedom directly on arc0, and sends packets
+   to the internet through freedom.  If you didn't know how to do the above,
+   you should probably stop reading this section now because it only gets
+   worse.
+
+   Now, how do I add patience into the network?  It will be using LANMAN
+   Client, which means I need the arc0e device.  It needs to be able to talk
+   to both insight and freedom, and also use freedom as a gateway to the
+   internet.  (Recall that patience has a "private IP address" which won't
+   work on the internet; that's okay, I configured Linux IP masquerading on
+   freedom for this subnet).
+   
+   So patience (necessarily; I don't have another IP number from my
+   provider) has an IP address on a different subnet than freedom and
+   insight, but needs to use freedom as an internet gateway.  Worse, most
+   DOS networking programs, including LANMAN, have braindead networking
+   schemes that rely completely on the netmask and a 'default gateway' to
+   determine how to route packets.  This means that to get to freedom or
+   insight, patience WILL send through its default gateway, regardless of
+   the fact that both freedom and insight (courtesy of the arc0e device)
+   could understand a direct transmission.
+   
+   I compensate by giving freedom an extra IP address - aliased 'gatekeeper'
+   - that is on my private subnet, the same subnet that patience is on.  I
+   then define gatekeeper to be the default gateway for patience.
+   
+   To configure freedom (in addition to the commands above):
+   	ifconfig arc0e gatekeeper
+   	route add gatekeeper arc0e
+   	route add patience arc0e
+   
+   This way, freedom will send all packets for patience through arc0e,
+   giving its IP address as gatekeeper (on the private subnet).  When it
+   talks to insight or the internet, it will use its "freedom" internet IP
+   address.
+   
+   You will notice that we haven't configured the arc0e device on insight. 
+   This would work, but is not really necessary, and would require me to
+   assign insight another special IP number from my private subnet.  Since
+   both insight and patience are using freedom as their default gateway, the
+   two can already talk to each other.
+   
+   It's quite fortunate that I set things up like this the first time (cough
+   cough) because it's really handy when I boot insight into DOS.  There, it
+   runs the Novell ODI protocol stack, which only works with RFC1201 ARCnet. 
+   In this mode it would be impossible for insight to communicate directly
+   with patience, since the Novell stack is incompatible with Microsoft's
+   Ethernet-Encap.  Without changing any settings on freedom or patience, I
+   simply set freedom as the default gateway for insight (now in DOS,
+   remember) and all the forwarding happens "automagically" between the two
+   hosts that would normally not be able to communicate at all.
+   
+   For those who like diagrams, I have created two "virtual subnets" on the
+   same physical ARCnet wire.  You can picture it like this:
+   
+                                                    
+          [RFC1201 NETWORK]                   [ETHER-ENCAP NETWORK]
+      (registered internet subnet)           (RFC1597 private subnet)
+  
+                             (IP Masquerade)
+          /---------------\         *            /---------------\
+          |               |         *            |               |
+          |               +-Freedom-*-Gatekeeper-+               |
+          |               |    |    *            |               |
+          \-------+-------/    |    *            \-------+-------/
+                  |            |                         |
+               Insight         |                      Patience
+                           (Internet)
+
+
+
+It works: what now?
+-------------------
+
+Send mail describing your setup, preferably including driver version, kernel
+version, ARCnet card model, CPU type, number of systems on your network, and
+list of software in use to me at the following address:
+	apenwarr@foxnet.net
+
+I do send (sometimes automated) replies to all messages I receive.  My email
+can be weird (and also usually gets forwarded all over the place along the
+way to me), so if you don't get a reply within a reasonable time, please
+resend.
+
+
+It doesn't work: what now?
+--------------------------
+
+Do the same as above, but also include the output of the ifconfig and route
+commands, as well as any pertinent log entries (ie. anything that starts
+with "arcnet:" and has shown up since the last reboot) in your mail.
+
+If you want to try fixing it yourself (I strongly recommend that you mail me
+about the problem first, since it might already have been solved) you may
+want to try some of the debug levels available.  For heavy testing on
+D_DURING or more, it would be a REALLY good idea to kill your klogd daemon
+first!  D_DURING displays 4-5 lines for each packet sent or received.  D_TX,
+D_RX, and D_SKB actually DISPLAY each packet as it is sent or received,
+which is obviously quite big.
+
+Starting with v2.40 ALPHA, the autoprobe routines have changed
+significantly.  In particular, they won't tell you why the card was not
+found unless you turn on the D_INIT_REASONS debugging flag.
+
+Once the driver is running, you can run the arcdump shell script (available
+from me or in the full ARCnet package, if you have it) as root to list the
+contents of the arcnet buffers at any time.  To make any sense at all out of
+this, you should grab the pertinent RFC's. (some are listed near the top of
+arcnet.c).  arcdump assumes your card is at 0xD0000.  If it isn't, edit the
+script.
+
+Buffers 0 and 1 are used for receiving, and Buffers 2 and 3 are for sending. 
+Ping-pong buffers are implemented both ways.
+
+If your debug level includes D_DURING and you did NOT define SLOW_XMIT_COPY,
+the buffers are cleared to a constant value of 0x42 every time the card is
+reset (which should only happen when you do an ifconfig up, or when Linux
+decides that the driver is broken).  During a transmit, unused parts of the
+buffer will be cleared to 0x42 as well.  This is to make it easier to figure
+out which bytes are being used by a packet.
+
+You can change the debug level without recompiling the kernel by typing:
+	ifconfig arc0 down metric 1xxx
+	/etc/rc.d/rc.inet1
+where "xxx" is the debug level you want.  For example, "metric 1015" would put
+you at debug level 15.  Debug level 7 is currently the default.
+
+Note that the debug level is (starting with v1.90 ALPHA) a binary
+combination of different debug flags; so debug level 7 is really 1+2+4 or
+D_NORMAL+D_EXTRA+D_INIT.  To include D_DURING, you would add 16 to this,
+resulting in debug level 23.
+
+If you don't understand that, you probably don't want to know anyway. 
+E-mail me about your problem.
+
+
+I want to send money: what now?
+-------------------------------
+
+Go take a nap or something.  You'll feel better in the morning.
diff --git a/Documentation/networking/ax25.txt b/Documentation/networking/ax25.txt
new file mode 100644
index 000000000..bcce0ff6b
--- /dev/null
+++ b/Documentation/networking/ax25.txt
@@ -0,0 +1,55 @@
+With the version of the AX.25, NET/ROM and Rose protocol stacks provided in
+the Linux kernel from 2.1.9 onwards, a change has occurred in the
+configuration of the protocols. With previous versions such changes were
+made via ioctl calls, but now use is being made of the sysctl interface.
+
+Each AX.25 device will be represented in the directory /proc/sys/net/ax25,
+in the form "dev.parms"  where dev is the device name, eg ax0. In it are a
+string of numbers that represent different values for the different
+parameters, they are: 
+
+No.	Name			Meaning				Default
+1	IP Default Mode		0=DG 1=VC			0
+2	AX.25 Default Mode	0=Normal 1=Extended		0
+3	Allow Vanilla Connects	0=No 1=Yes			1
+4	Backoff			0=Linear 1=Exponential		1
+5	Connected Mode		0=No 1=Yes			1
+6	Standard Window		1  <= N <= 7			2
+7	Extended Window		1  <= N <= 63			32
+8	T1 Timeout		1s <= N <= 30s			10s
+9	T2 Timeout		1s <= N <= 20s			3s
+10	T3 Timeout		0s <= N <= 3600s		300s
+11	Idle Timeout		0m <= N				20m
+12	N2			1  <= N <= 31			10
+13	AX.25 MTU		1  <= N <= 512			256
+14	Max Queue		1  <= N <= 20			2
+15	Digipeater Mode		0=None 1=Inband 2=XBand 3=Both	3
+
+In the above list T1, T2 and T3 are given in seconds, and the Idle Timeout
+is given in minutes. But please note that the values used in the sysctl
+interface are given in internal units where the time in seconds is
+multiplied by 10, this allows resolution down to 1/10 of a second. With
+timers that are allowed to be zero, eg T3 and Idle, a zero value indicates
+that the timer is disabled. 
+
+With NET/ROM and Rose protocol stacks, the entries in /proc/sys/net/netrom
+and /proc/sys/net/rose are more obvious. Each file in these directories has
+a name more in keeping with its function, and will not be explained in any
+greater depth here. As with the AX.25 sysctl entries, timers operate with a
+resolution of 100ms and so values should be written accordingly.
+
+It is possible that the AX.25 sysctl interface will change in the future and
+become more user friendly.
+
+For more information about the AX.25 and NET/ROM protocol stacks, see the
+AX25-HOWTO written by Terry Dawson <terry@perf.no.itg.telstra.com.au> who is
+also the AX.25 Utilities maintainer.
+
+There is an active mailing list for discussing Linux amateur radio matters
+called linux-hams. To subscribe to it, send a message to
+majordomo@vger.rutgers.edu with the words "subscribe linux-hams" in the body
+of the message, the subject field is ignored.
+
+Jonathan G4KLX
+
+jsn@cs.nott.ac.uk
diff --git a/Documentation/networking/framerelay.txt b/Documentation/networking/framerelay.txt
new file mode 100644
index 000000000..f02b133d1
--- /dev/null
+++ b/Documentation/networking/framerelay.txt
@@ -0,0 +1,39 @@
+Frame Relay (FR) support for linux is built into a two tiered system of device 
+drivers.  The upper layer implements RFC1490 FR specification, and uses the
+Data Link Connection Identifier (DLCI) as its hardware address.  Usually these
+are assigned by your network supplier, they give you the number/numbers of
+the Virtual Connections (VC) assigned to you.
+
+Each DLCI is a point-to-point link between your machine and a remote one.
+As such, a separate device is needed to accommodate the routing.  Within the
+net-tools archives is 'dlcicfg'.  This program will communicate with the
+base "DLCI" device, and create new net devices named 'dlci00', 'dlci01'... 
+The configuration script will ask you how many DLCI's you need, as well as
+how many DLCI's you want to assign to each Frame Relay Access Device (FRAD).
+
+The DLCI uses a number of function calls to communicate with the FRAD, all
+of which are stored in the FRAD's private data area.  assoc/deassoc, 
+activate/deactivate and dlci_config.  The DLCI supplies a receive function
+to the FRAD to accept incoming packets.
+
+With this initial offering, only 1 FRAD driver is available.  With many thanks
+to Sangoma Technologies, David Mandelstam & Gene Kozin, the S502A, S502E & 
+S508 are supported.  This driver is currently set up for only FR, but as 
+Sangoma makes more firmware modules available, it can be updated to provide
+them as well.
+
+Configuration of the FRAD makes use of another net-tools program, 'fradcfg'.
+This program makes use of a configuration file (which dlcicfg can also read)
+to specify the types of boards to be configured as FRADs, as well as perform
+any board specific configuration.  The Sangoma module of fradcfg loads the
+FR firmware into the card, sets the irq/port/memory information, and provides
+an initial configuration.
+
+Additional FRAD device drivers can be added as hardware is available.
+
+At this time, the dlcicfg and fradcfg programs have not been incorporated into
+the net-tools distribution.  They can be found at ftp.invlogic.com, in 
+/pub/linux.  Note that with OS/2 FTPD, you end up in /pub by default, so just
+use 'cd linux'.  v0.10 is for use on pre-2.0.3 and earlier, v0.15 is for 
+pre-2.0.4 and later.
+
diff --git a/Documentation/networking/ncsa-telnet b/Documentation/networking/ncsa-telnet
new file mode 100644
index 000000000..d77d28b09
--- /dev/null
+++ b/Documentation/networking/ncsa-telnet
@@ -0,0 +1,16 @@
+NCSA telnet doesn't work with path MTU discovery enabled. This is due to a
+bug in NCSA that also stops it working with other modern networking code
+such as Solaris.
+
+The following information is courtesy of 
+Marek <marekm@i17linuxb.ists.pwr.wroc.pl>
+
+There is a fixed version somewhere on ftp.upe.ac.za (sorry, I don't
+remember the exact pathname, and this site is very slow from here).
+It may or may not be faster for you to get it from
+ftp://ftp.ists.pwr.wroc.pl/pub/msdos/telnet/ncsa_upe/tel23074.zip
+(source is in v230704s.zip).  I have tested it with 1.3.79 (with
+path mtu discovery enabled - ncsa 2.3.08 didn't work) and it seems
+to work.  I don't know if anyone is working on this code - this
+version is over a year old.  Too bad - it's faster and often more
+stable than these windoze telnets, and runs on almost anything...
diff --git a/Documentation/networking/net-modules.txt b/Documentation/networking/net-modules.txt
new file mode 100644
index 000000000..5ef6cca57
--- /dev/null
+++ b/Documentation/networking/net-modules.txt
@@ -0,0 +1,294 @@
+Wed 2-Aug-95  <matti.aarnio@utu.fi>
+
+		Linux network driver modules
+
+	Do not mistake this to "README.modules" at the top-level
+	directory!  That document tells about modules in general, while
+	this one tells only about network device driver modules.
+
+	This is a potpourri of INSMOD-time(*) configuration options
+	(if such exists) and their default values of various modules
+	on Linux network drivers collection.
+
+	Some modules have also hidden (= non-documented) tunable values.
+	Choice of not documenting them is based on general belief, that
+	the less user needs to know, the better.  (There are things that
+	driver developer can use, others should not confuse themselves.)
+
+	In many cases it is highly preferred that insmod:ing is done
+	ONLY with defining an explicit address for the card, AND BY
+	NOT USING AUTO-PROBING!
+
+	Now most cards have some explicitly defined base address, they
+	are compiled with (to avoid auto-probing, among other things).
+	If that compiled value does not match your actual configuration,
+	do use  "io=0xXXX" -parameter for the  insmod, and give there
+	a value matching your environment.
+
+	If you are adventurous, you can ask the driver to autoprobe
+	by using "io=0" parameter, however it is potentially dangerous
+	thing to do in a live system.  (If you don't know where the
+	card is located, you can try autoprobing, and after possible
+	crash recovery, insmod with proper IO-address..)
+
+	--------------------------
+	(*)	"INSMOD-time" means when you load module with
+		/sbin/insmod  you can feed it optional parameters.
+		See "man insmod".
+	--------------------------
+
+
+	8390 based Network Modules		(Paul Gortmaker, Nov 12, 1995)
+	--------------------------
+
+(Includes: smc-ultra, ne, wd, 3c503, hp, hp-plus, e2100 and ac3200)
+
+The 8390 series of network drivers now support multiple card systems without 
+reloading the same module multiple times (memory efficient!) This is done by 
+specifying multiple comma separated values, such as:
+
+	insmod 3c503.o io=0x280,0x300,0x330,0x350  xcvr=0,1,0,1
+
+The above would have the one module controlling four 3c503 cards, with card 2
+and 4 using external transceivers. The "insmod" manual describes the usage
+of comma separated value lists.
+
+It is *STRONGLY RECOMMENDED* that you supply "io=" instead of autoprobing.
+If an "io=" argument is not supplied, then the ISA drivers will complain
+about autoprobing being not recommended, and begrudgingly autoprobe for
+a *SINGLE CARD ONLY* -- if you want to use multiple cards you *have* to 
+supply an "io=0xNNN,0xQQQ,..." argument.
+
+The ne module is an exception to the above. A NE2000 is essentially an
+8390 chip, some bus glue and some RAM. Because of this, the ne probe is
+more invasive than the rest, and so at boot we make sure the ne probe is 
+done last of all the 8390 cards (so that it won't trip over other 8390 based
+cards) With modules we can't ensure that all other non-ne 8390 cards have
+already been found. Because of this, the ne module REQUIRES an "io=0xNNN" 
+argument passed in via insmod. It will refuse to autoprobe.
+
+It is also worth noting that auto-IRQ probably isn't as reliable during 
+the flurry of interrupt activity on a running machine. Cards such as the 
+ne2000 that can't get the IRQ setting from an EEPROM or configuration
+register are probably best supplied with an "irq=M" argument as well.
+
+
+----------------------------------------------------------------------
+Card/Module List - Configurable Parameters and Default Values
+----------------------------------------------------------------------
+
+3c501.c:
+	io  = 0x280	IO base address
+	irq = 5		IRQ
+	(Probes ports:	0x280, 0x300)
+
+3c503.c:
+	io = 0		(It will complain if you don't supply an "io=0xNNN")
+	irq = 0		(IRQ software selected by driver using autoIRQ)
+	xcvr = 0	(Use xcvr=1 to select external transceiver.)
+	(Probes ports: 0x300, 0x310, 0x330, 0x350, 0x250, 0x280, 0x2A0, 0x2E0)
+
+3c505.c:
+	io = 0
+	irq = 0
+	dma = 6         (not autoprobed)
+	(Probes ports: 0x300, 0x280, 0x310)
+
+3c507.c:
+	io = 0x300
+	irq = 0
+	(Probes ports: 0x300, 0x320, 0x340, 0x280)
+
+3c509.c:
+	io = 0
+	irq = 0
+	( Module load-time probing Works reliably only on EISA, ISA ID-PROBE
+	  IS NOT RELIABLE!  Compile this driver statically into kernel for
+	  now, if you need it auto-probing on an ISA-bus machine. )
+
+8390.c:
+	(No public options, several other modules need this one)
+
+ac3200.c:
+	io = 0		(Checks 0x1000 to 0x8fff in 0x1000 intervals)
+	irq = 0		(Read from config register)
+	(EISA probing..)
+
+apricot.c:
+	io = 0x300  (Can't be altered!)
+	irq = 10
+
+arcnet.c:
+	io = 0
+	irqnum = 0
+	shmem = 0
+	num = 0
+	DO SET THESE MANUALLY AT INSMOD!
+	(When probing, looks at the following possible addresses:
+	 Suggested ones:
+		0x300, 0x2E0, 0x2F0, 0x2D0
+	 Other ones:
+		0x200, 0x210, 0x220, 0x230, 0x240, 0x250, 0x260, 0x270,
+		0x280, 0x290, 0x2A0, 0x2B0, 0x2C0,
+		       0x310, 0x320, 0x330, 0x340, 0x350, 0x360, 0x370,
+		0x380, 0x390, 0x3A0,			  0x3E0, 0x3F0  )
+
+at1700.c:
+	io = 0x260
+	irq = 0
+	(Probes ports: 0x260, 0x280, 0x2A0, 0x240, 0x340, 0x320, 0x380, 0x300)
+
+atp.c: *Not modularized*
+	(Probes ports: 0x378, 0x278, 0x3BC;
+	 fixed IRQs: 5 and 7			)
+
+de4x5.c:
+	io = 0x000b
+	irq = 10
+	is_not_dec = 0  -- For non-DEC card using DEC 21040/21041/21140 chip, set this to 1
+	(EISA, and PCI probing)
+
+de600.c:
+	de600_debug = 0
+	(On port 0x378, irq 7 -- lpt1;  compile time configurable)
+
+de620.c:
+	bnc = 0, utp = 0  <-- Force media by setting either.
+	io = 0x378	(also compile-time configurable)
+	irq = 7
+
+depca.c:
+	io = 0x200
+	irq = 7
+	(Probes ports:	ISA:  0x300, 0x200;
+			EISA: 0x0c00		)
+
+dummy.c:
+	No options
+
+e2100.c:
+	io = 0		(It will complain if you don't supply an "io=0xNNN")
+	irq = 0		(IRQ software selected by driver)
+	mem = 0		(Override default shared memory start of 0xd0000)
+	xcvr = 0	(Use xcvr=1 to select external transceiver.)
+	(Probes ports: 0x300, 0x280, 0x380, 0x220)
+
+eepro.c:
+	io = 0x200
+	irq = 0
+	(Probes ports: 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340, 0x360)
+
+eexpress.c:
+	io = 0x300
+	irq = 0		(IRQ value read from EEPROM)
+	(Probes ports: 0x300, 0x270, 0x320, 0x340)
+
+eql.c:
+	(No parameters)
+
+ewrk3.c:
+	io = 0x300
+	irq = 5
+	(With module no autoprobing!
+	 On EISA-bus does EISA probing.
+	 Static linkage probes ports on ISA bus:
+		0x100, 0x120, 0x140, 0x160, 0x180, 0x1A0, 0x1C0,
+		0x200, 0x220, 0x240, 0x260, 0x280, 0x2A0, 0x2C0, 0x2E0,
+		0x300,        0x340, 0x360, 0x380, 0x3A0, 0x3C0)
+
+hp-plus.c:
+	io = 0		(It will complain if you don't supply an "io=0xNNN")
+	irq = 0		(IRQ read from configuration register)
+	(Probes ports: 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340)
+
+hp.c:
+	io = 0		(It will complain if you don't supply an "io=0xNNN")
+	irq = 0		(IRQ software selected by driver using autoIRQ)
+	(Probes ports: 0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200, 0x240)
+
+hp100.c:
+	hp100_port = 0 (IO-base address)
+	(Does EISA-probing, if on EISA-slot;
+	 On ISA-bus probes all ports from 0x100 thru to 0x3E0
+	 in increments of 0x020)
+
+ibmtr.c:
+	io = 0xA20
+	(Probes ports: 0xA20, 0xA24 -- Ok, 0x220, 0x224, but IBM style..)
+
+lance.c: *Not modularized*
+	(PCI, and ISA probing; "CONFIG_PCI" needed for PCI support)
+	(Probes ISA ports: 0x300, 0x320, 0x340, 0x360)
+
+loopback.c: *Static kernel component*
+
+ne.c:
+	io = 0		(Explicitly *requires* an "io=0xNNN" value)
+	irq = 0		(Tries to determine configured IRQ via autoIRQ)
+	(Probes ports: 0x300, 0x280, 0x320, 0x340, 0x360)
+
+net_init.c: *Static kernel component*
+
+ni52.c: *Not modularized*
+	(Probes ports:	0x300, 0x280, 0x360, 0x320, 0x340
+		mems:	0xD0000, 0xD2000, 0xC8000, 0xCA000,
+			0xD4000, 0xD6000, 0xD8000 )
+
+ni65.c: *Not modularized*  **16MB MEMORY BARRIER BUG**
+	(Probes ports:	0x300, 0x320, 0x340, 0x360)
+
+pi2.c:	*Not modularized* (well, NON-STANDARD modularization!)
+	Only one card supported at this time.
+	(Probes ports: 0x380, 0x300, 0x320, 0x340, 0x360, 0x3A0)
+
+plip.c:
+	io = 0
+	irq = 0		(by default, uses IRQ 5 for port at 0x3bc, IRQ 7
+			for port at 0x378, and IRQ 2 for port at 0x278)
+	(Probes ports: 0x278, 0x378, 0x3bc)
+
+ppp.c:
+	No options (ppp-2.2+ has some, this is based on non-dynamic
+	version from ppp-2.1.2d)
+
+seeq8005.c: *Not modularized*
+	(Probes ports: 0x300, 0x320, 0x340, 0x360)
+
+sk_g16.c: *Not modularized*
+	(Probes ports: 0x100, 0x180, 0x208, 0x220m 0x288, 0x320, 0x328, 0x390)
+
+skeleton.c: *Skeleton*
+
+slhc.c:
+	No configuration parameters
+
+slip.c:
+	slip_maxdev = 256 (default value from SL_NRUNIT on slip.h)
+
+
+smc-ultra.c:
+	io = 0		(It will complain if you don't supply an "io=0xNNN")
+	irq = 0		(IRQ val. read from EEPROM)
+	(Probes ports:	0x200, 0x220, 0x240, 0x280, 0x300, 0x340, 0x380)
+
+tulip.c: *Partial modularization*
+	(init-time memory allocation makes problems..)
+
+tunnel.c:
+	No insmod parameters
+
+wavelan.c:
+	io = 0x390	(Settable, but change not recommended)
+	irq = 0		(Not honoured, if changed..)
+
+wd.c:
+	io = 0		(It will complain if you don't supply an "io=0xNNN")
+	irq = 0		(IRQ val. read from EEPROM, ancient cards use autoIRQ)
+	mem = 0		(Force shared-memory on address 0xC8000, or whatever..)
+	mem_end = 0	(Force non-std. mem. size via supplying mem_end val.)
+			(eg. for 32k WD8003EBT, use mem=0xd0000 mem_end=0xd8000)
+	(Probes ports:	0x300, 0x280, 0x380, 0x240)
+
+znet.c: *Not modularized*
+	(Only one device on  Zenith Z-Note (notebook?) systems,
+	 configuration information from (EE)PROM)
diff --git a/Documentation/networking/ppp.txt b/Documentation/networking/ppp.txt
new file mode 100644
index 000000000..917fb869f
--- /dev/null
+++ b/Documentation/networking/ppp.txt
@@ -0,0 +1,25 @@
+The PPP support for this kernel requires the 2.2.0 version of the
+pppd daemon. You will find the current version of the daemon on
+sunsite.unc.edu in the /pub/Linux/system/Network/serial directory.
+
+Sunsite has many mirror sites. Please feel free to obtain it from
+a mirror site close to you.
+
+If you attempt to use a version of pppd which is not compatible
+then you will have some error condition. It usually is reflected
+in that an ioctl operation will generate a fatal error.
+
+Please do not use earlier versions of the 2.2 package. If you
+obtained a copy from merit.edu or bellatrix then please get an
+update from the sunsite site.
+
+The CCP (Compression Control Protocol) which is supported by this
+code is functional. You will need a compatible BSD compressor on
+your peer site to use the code.
+
+The BSD compression code will only build as a loadable module. There
+was an earlier version which would build it into the kernel but that
+functionality has been removed for various reasons.
+
+--
+Al Longyear                      longyear@netcom.com
diff --git a/Documentation/networking/tcp.txt b/Documentation/networking/tcp.txt
new file mode 100644
index 000000000..717490070
--- /dev/null
+++ b/Documentation/networking/tcp.txt
@@ -0,0 +1,39 @@
+How the new TCP output machine [nyi] works.
+
+
+Data is kept on a single queue. The skb->users flag tells us if the frame is
+one that has been queued already. To add a frame we throw it on the end. Ack
+walks down the list from the start.
+
+We keep a set of control flags
+
+
+	sk->tcp_pend_event
+
+		TCP_PEND_ACK			Ack needed
+		TCP_ACK_NOW			Needed now
+		TCP_WINDOW			Window update check
+		TCP_WINZERO			Zero probing
+
+
+	sk->transmit_queue		The transmission frame begin
+	sk->transmit_new		First new frame pointer
+	sk->transmit_end		Where to add frames
+
+	sk->tcp_last_tx_ack		Last ack seen
+	sk->tcp_dup_ack			Dup ack count for fast retransmit
+
+
+Frames are queued for output by tcp_write. We do our best to send the frames
+off immediately if possible, but otherwise queue and compute the body
+checksum in the copy. 
+
+When a write is done we try to clear any pending events and piggy back them.
+If the window is full we queue full sized frames. On the first timeout in
+zero window we split this.
+
+On a timer we walk the retransmit list to send any retransmits, update the
+backoff timers etc. A change of route table stamp causes a change of header
+and recompute. We add any new tcp level headers and refinish the checksum
+before sending. 
+
diff --git a/Documentation/networking/tulip.txt b/Documentation/networking/tulip.txt
new file mode 100644
index 000000000..45533ec1b
--- /dev/null
+++ b/Documentation/networking/tulip.txt
@@ -0,0 +1,110 @@
+                Tulip ethernet card driver
+
+The Tulip driver is developed by Donald Becker and changed by
+Takashi Manabe. This driver is designed to work with PCI ethernet
+cards which use the DECchip DC21x4x family. This driver hopefully
+works with all of 1.2.x and 1.3.x kernels, but I tested only
+with 1.2.13, 1.3.39, 1.3.49, 1.3.52, 1.3.57 and later.
+
+Hopefully, the de4x5.c driver will support all cards supported
+by the tulip.c driver. However, the SMC's 9332dst card and some
+cards do not work with the de4x5.c driver. So, if your card is
+not a 9332dst, please try the de4x5.c driver first.
+
+Success List
+============
+
++-------------------------------------+-----------+-------------+
+|vendor/card                          |chip       |system       |
++-------------------------------------+-----------+-------------+
+|SMC                                  |           |             |
+|     EtherPower 10 PCI(8432T/8432BT) |21040/21041|Pentium      |
++-------------------------------------+-----------+-------------+
+|SMC                                  |           |             |
+|     EtherPower 10/100 PCI(9332DST)  |21140      |Pentium/UDB  |
++-------------------------------------+-----------+-------------+
+|DEC                                  |           |             |
+|     EtherWorks 100/10 PCI(DE500-XA) |21140      |Pentium      |
++-------------------------------------+-----------+-------------+
+|DEC                                  |           |             |
+|     EtherWorks 10 PCI(DE450)        |21041      |Pentium      |
++-------------------------------------+-----------+-------------+
+|DEC                                  |           |             |
+|     QSILVER's                       |21040      |UDB          |
++-------------------------------------+-----------+-------------+
+|ZNYX                                 |           |             |
+|     312 etherarray                  |21040      |Pentium      |
++-------------------------------------+-----------+-------------+
+|Allied Telesis                       |           |             |
+|     LA100PCI-T                      |21140      |Pentium/UDB  |
++-------------------------------------+-----------+-------------+
+|Danpex ('Planet Japan' in Japan?)    |           |             |
+|     EN-9400                         |21040      |Pentium      |
++-------------------------------------+-----------+-------------+
+|Cogent                               |           |             |
+|     EM110                           |21140      |Pentium      |
++-------------------------------------+-----------+-------------+
+
+Pentium: PCI machine with Pentium CPU
+UDB:     Universal Desktop Box(aka Multia) with Alpha 21066 CPU
+
+Known bug(s)
+============
+This driver's media detection is very simple and sometimes
+it causes serious problem. The driver automatically switches
+media when it causes timeout. If you want to specify or to fix
+a media;
+
+- Modify TULIP_PORT in tulip.c, line 33.
+- Uncomment the definition of TULIP_FIX_PORT in tulip.c, line 40.
+
+or
+
+- Use patched ifconfig command and specify 'link='. The patch
+  against ifconfig.c in net-tools-1.3.50-BETA6e is included in
+  this file.
+
+Thanks
+======
+
+o becker@CESDIS.gsfc.nasa.gov (author of the tulip.c driver)
+o davies@wanton.lkg.dec.com (author of the de4x5.c driver)
+
+o siekas@mailhost.tcs.tulane.edu
+
+o jheiss@calvin.caltech.edu (providing information about smc8432 card)
+o goto@plathome.co.jp (lending me a DE450 card)
+o ted@physics.ucsb.edu
+o pmheuvel@xs4all.nl
+o hjl@lucon.org (EN-9400)
+o niles@axp745.gsfc.nasa.gov (ZNYX312)
+o pkc@scs.carleton.ca (EM110)
+o and testers...
+
+-----------------------------------------------------------------------
+*** ifconfig.c-dist	Wed Jan 17 07:25:36 1996
+--- ifconfig.c	Tue Apr  9 15:24:25 1996
+***************
+*** 765,770 ****
+--- 766,786 ----
+  			continue;
+  		}
+  		ifr.ifr_map.irq = atoi(*spp);
++ 		if (ioctl(skfd, SIOCSIFMAP, &ifr) < 0) {
++ 			fprintf(stderr, "SIOCSIFMAP: %s\n", strerror(errno));
++ 			goterr = 1;
++ 		}
++ 		spp++;
++ 		continue;
++ 	}
++ 
++ 	if (!strcmp(*spp, "link")) {
++ 		if (*++spp == NULL) usage();
++ 		if (ioctl(skfd, SIOCGIFMAP, &ifr) < 0) {
++ 			goterr = 1;
++ 			continue;
++ 		}
++ 		ifr.ifr_map.port = atoi(*spp);
+  		if (ioctl(skfd, SIOCSIFMAP, &ifr) < 0) {
+  			fprintf(stderr, "SIOCSIFMAP: %s\n", strerror(errno));
+  			goterr = 1;
diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt
new file mode 100644
index 000000000..413aadf91
--- /dev/null
+++ b/Documentation/networking/vortex.txt
@@ -0,0 +1,35 @@
+This document describes the usage and errata of the 3Com "Vortex" device
+driver for Linux.
+
+This driver supports the following hardware:
+	3c590, 3c592, 3c595, 3c597
+
+When loaded as a module the following variables may be set:
+ name	 type	description
+ debug	 int	The debug message level, 0 (no messages) to 6 (wordy).
+ options int[]	The media type override and card operation settings
+		(See list below.)
+
+An example of loading the vortex module is
+	insmod 3c59x.o debug=1 options=0,,12
+This sets the debug message level to minimal messages, sets the first card to
+the 10baseT transceiver, the second to the EEPROM-set transceiver, and the
+third card to operate in full-duplex mode using its 100baseTx transceiver.
+(Note: card ordering is set by the PCI BIOS.)
+
+Possible media type settings
+	0	10baseT
+	1	10Mbs AUI
+	2	undefined
+	3	10base2 (BNC)
+	4	100base-TX
+	5	100base-FX
+	6	MII (not yet available)
+	7	<Use default setting>
+	
+	8	Full-duplex bit
+		8 10baseT full-duplex
+		12 100baseTx full-duplex 
+	16	Bus-master enable bit (experimental use only!)
+
+Details of the device driver implementation are at the top of the source file.
diff --git a/Documentation/networking/z8530drv.txt b/Documentation/networking/z8530drv.txt
new file mode 100644
index 000000000..67c842ee6
--- /dev/null
+++ b/Documentation/networking/z8530drv.txt
@@ -0,0 +1,654 @@
+This is a subset of the documentation. To use this driver you MUST have the
+full package from:
+
+Internet:
+=========
+
+1. db0bm.automation.fh-aachen.de/incoming/dl1bke/z8530drv-utils-3.0.tar.gz
+
+2. ftp.ucsd.edu:/hamradio/packet/tcpip/incoming/z8530drv-utils-3.0.tar.gz
+   If you can't find it there, try .../tcpip/linux/z8530drv-utils-3.0.tar.gz
+
+and various mirrors (i.e. nic.switch.ch)
+
+Please note that the information in this document may be hopelessly outdated.
+-----------------------------------------------------------------------------
+
+
+	 SCC.C - Linux driver for Z8530 based HDLC cards for AX.25      
+
+   ********************************************************************
+
+        (c) 1993,1996 by Joerg Reuter DL1BKE <jreuter@lykos.oche.de>
+
+        portions (c) 1993 Guido ten Dolle PE1NNZ
+
+        for the complete copyright notice see >> Copying.Z8530DRV <<
+
+   ******************************************************************** 
+
+
+1. Initialization of the driver
+===============================
+
+To use the driver, 3 steps must be performed:
+
+     1. if compiled as module: loading the module
+     2. Setup of hardware, MODEM and KISS parameters with sccinit
+     3. Attach each channel to the Linux kernel AX.25 with "ifconfig"
+
+Unlike the versions below 2.4 this driver is a real network device
+driver. If you want to run xNOS instead of our fine kernel AX.25
+use a 2.x version (available from above sites) or read the
+AX.25-HOWTO on how to emulate a KISS TNC on network device drivers.
+
+
+1.1 Loading the module
+======================
+
+(If you're going to compile the driver as a part of the kernel image,
+ skip this chapter and continue with 1.2)
+
+Before you can use a module, you'll have to load it with
+
+	insmod scc.o
+
+please read 'man insmod' that comes with modutils.
+
+You should include the insmod in one of the /etc/rc.d/rc.* files,
+and don't forget to insert a call of sccinit after that. It
+will read your /etc/z8530drv.conf.
+
+1.2. /etc/z8530drv.conf
+=======================
+
+To setup all parameters you must run /sbin/sccinit from one
+of your rc.*-files. This has to be done BEFORE you can
+"ifconfig" an interface. Sccinit reads the file /etc/z8530drv.conf
+and sets the hardware, MODEM and KISS parameters. A sample file is
+delivered with this package. Change it to your needs.
+
+The file itself consists of two main sections.
+
+1.2.1 configuration of hardware parameters
+==========================================
+
+The hardware setup section defines the following parameters for each
+Z8530:
+
+chip    1
+data_a  0x300                   # data port A
+ctrl_a  0x304                   # control port A
+data_b  0x301                   # data port B
+ctrl_b  0x305                   # control port B
+irq     5                       # IRQ No. 5
+pclock  4915200                 # clock
+board   BAYCOM                  # hardware type
+escc    no                      # enhanced SCC chip? (8580/85180/85280)
+vector  0                       # latch for interrupt vector
+special no                      # address of special function register
+option  0                       # option to set via sfr
+
+
+chip	- this is just a delimiter to make sccinit a bit simpler to
+	  program. A parameter has no effect.
+
+data_a  - the address of the data port A of this Z8530 (needed)
+ctrl_a  - the address of the control port A (needed)
+data_b  - the address of the data port B (needed)
+ctrl_b  - the address of the control port B (needed)
+
+irq     - the used IRQ for this chip. Different chips can use different
+          IRQs or the same. If they share an interrupt, it needs to be
+	  specified within one chip-definition only.
+
+pclock  - the clock at the PCLK pin of the Z8530 (option, 4915200 is
+          default), measured in Hertz
+
+board   - the "type" of the board:
+
+	   SCC type                 value
+	   ---------------------------------
+	   PA0HZP SCC card          PA0HZP
+	   EAGLE card               EAGLE
+	   PC100 card               PC100
+	   PRIMUS-PC (DG9BL) card   PRIMUS
+	   BayCom (U)SCC card       BAYCOM
+
+escc    - if you want support for ESCC chips (8580, 85180, 85280), set
+          this to "yes" (option, defaults to "no")
+
+vector  - address of the vector latch (aka "intack port") for PA0HZP
+          cards. There can be only one vector latch for all chips!
+	  (option, defaults to 0)
+
+special - address of the special function register on several cards.
+          (option, defaults to 0)
+
+option  - The value you write into that register (option, default is 0)
+
+You can specify up to four chips (8 channels). If this is not enough,
+just change
+
+	#define MAXSCC 4
+
+to a higher value.
+
+Example for the BayCom USCC:
+----------------------------
+
+chip    1
+data_a  0x300                   # data port A
+ctrl_a  0x304                   # control port A
+data_b  0x301                   # data port B
+ctrl_b  0x305                   # control port B
+irq     5                       # IRQ No. 5 (#)
+board   BAYCOM                  # hardware type (*)
+#
+# SCC chip 2
+#
+chip    2
+data_a  0x302
+ctrl_a  0x306
+data_b  0x303
+ctrl_b  0x307
+board   BAYCOM
+
+An example for a PA0HZP card:
+-----------------------------
+
+chip 1
+data_a 0x153
+data_b 0x151
+ctrl_a 0x152
+ctrl_b 0x150
+irq 9
+pclock 4915200
+board PA0HZP
+vector 0x168
+escc no
+#
+#
+#
+chip 2
+data_a 0x157
+data_b 0x155
+ctrl_a 0x156
+ctrl_b 0x154
+irq 9
+pclock 4915200
+board PA0HZP
+vector 0x168
+escc no
+
+A DRSI would should probably work with this:
+--------------------------------------------
+(actually: two DRSI cards...)
+
+chip 1
+data_a 0x303
+data_b 0x301
+ctrl_a 0x302
+ctrl_b 0x300
+irq 7
+pclock 4915200
+board DRSI
+escc no
+#
+#
+#
+chip 2
+data_a 0x313
+data_b 0x311
+ctrl_a 0x312
+ctrl_b 0x310
+irq 7
+pclock 4915200
+board DRSI
+escc no
+
+Note that you cannot use the on-board baudrate generator off DRSI
+cards. Use "mode dpll" for clock source (see below).
+
+This is based on information provided by Mike Bilow (and verified
+by Paul Helay)
+
+The utility "gencfg"
+--------------------
+
+If you only know the parameters for the PE1CHL driver for DOS,
+run gencfg. It will generate the correct port addresses (I hope).
+Its parameters are exactly the same as the ones you use with
+the "attach scc" command in net, except that the string "init" must 
+not appear. Example:
+
+gencfg 2 0x150 4 2 0 1 0x168 9 4915200 
+
+will print a skeleton z8530drv.conf for the OptoSCC to stdout.
+
+gencfg 2 0x300 2 4 5 -4 0 7 4915200 0x10
+
+does the same for the BayCom USCC card. I my opinion it is much easier
+to edit scc_config.h... 
+
+
+1.2.2 channel configuration
+===========================
+
+The channel definition is divided into three sub sections for each
+channel:
+
+An example for scc0:
+
+# DEVICE
+
+device scc0	# the device for the following params
+
+# MODEM / BUFFERS
+
+speed 1200		# the default baudrate
+clock dpll		# clock source: 
+			# 	dpll     = normal halfduplex operation
+			# 	external = MODEM provides own Rx/Tx clock
+			#	divider  = use fullduplex divider if
+			#		   installed (1)
+mode nrzi		# HDLC encoding mode
+			#	nrzi = 1k2 MODEM, G3RUH 9k6 MODEM
+			#	nrz  = DF9IC 9k6 MODEM
+			#
+bufsize	384		# size of buffers. Note that this must include
+			# the AX.25 header, not only the data field!
+			# (optional, defaults to 384)
+
+# KISS (Layer 1)
+
+txdelay 36              # (see chapter 1.4)
+persist 64
+slot    8
+tail    8
+fulldup 0
+wait    12
+min     3
+maxkey  7
+idle    3
+maxdef  120
+group   0
+txoff   off
+softdcd on                   
+slip    off
+
+The order WITHIN these sections is unimportant. The order OF these
+sections IS important. The MODEM parameters are set with the first
+recognized KISS parameter...
+
+Please note that you can initialize the board only once after boot
+(or insmod). You can change all parameters but "mode" and "clock" 
+later with the Sccparam program or through KISS. Just to avoid 
+security holes... 
+
+(1) this divider is usually mounted on the SCC-PBC (PA0HZP) or not
+    present at all (BayCom). It feeds back the output of the DPLL 
+    (digital pll) as transmit clock. Using this mode without a divider 
+    installed will normally result in keying the transceiver until 
+    maxkey expires --- of course without sending anything (useful).
+
+2. Attachment of a channel by your AX.25 software
+=================================================
+
+2.1 Kernel AX.25
+================
+
+To set up an AX.25 device you can simply type:
+
+	ifconfig scc0 44.128.1.1 hw ax25 dl0tha-7
+
+This will create a network interface with the IP number 44.128.20.107 
+and the callsign "dl0tha". If you do not have any IP number (yet) you 
+can use any of the 44.128.0.0 network. Note that you do not need 
+axattach. The purpose of axattach (like slattach) is to create a KISS 
+network device linked to a TTY. Please read the documentation of the 
+ax25-utils and the AX.25-HOWTO to learn how to set the parameters of
+the kernel AX.25.
+
+2.2 NOS, NET and TFKISS
+=======================
+
+Since the TTY driver (aka KISS TNC emulation) is gone you need
+to emulate the old behaviour. The cost using these programs is
+that you probably need to compile the kernel AX.25, regardless 
+if you actually use it or not. First setup your /etc/ax25/axports,
+for example:
+
+	9k6	dl0tha-9  9600  255 4 9600 baud port (scc3)
+	axlink	dl0tha-15 38400 255 4 Link to NOS
+
+Now "ifconfig" the scc device:
+
+	ifconfig scc3 44.128.1.1 hw ax25 dl0tha-9
+
+You can now axattach a pseudo-TTY:
+
+	axattach /dev/ptys0 axlink
+
+and start your NOS and attach /dev/ptys0 there. The problem is that
+NOS is reachable only via digipeating through the kernel AX.25
+(disasterous on a DAMA controlled channel). To solve this problem,
+configure "rxecho" to echo the incoming frames from "9k6" to "axlink"
+and outgoing frames from "axlink" to "9k6" and start:
+
+	rxecho
+
+Or simply use "kissbridge" coming with z8530drv-utils:
+
+	ifconfig scc3 hw ax25 dl0tha-9
+	kissbridge scc3 /dev/ptys0
+
+
+3. Adjustment and Display of parameters
+=======================================
+
+3.1 Displaying SCC Parameters:
+==============================
+
+Once a SCC channel has been attached, the parameter settings and 
+some statistic information can be shown using the param program:
+
+dl1bke-u:~$ sccstat scc0
+
+Parameters:
+
+speed       : 1200 baud
+txdelay     : 36
+persist     : 255
+slottime    : 0
+txtail      : 8
+fulldup     : 1
+waittime    : 12
+mintime     : 3 sec
+maxkeyup    : 7 sec
+idletime    : 3 sec
+maxdefer    : 120 sec
+group       : 0x00
+txoff       : off
+softdcd     : on
+SLIP        : off
+
+Status:
+
+HDLC                  Z8530           Interrupts         Buffers
+-----------------------------------------------------------------------
+Sent       :     273  RxOver :     0  RxInts :   125074  Size    :  384
+Received   :    1095  TxUnder:     0  TxInts :     4684  NoSpace :    0
+RxErrors   :    1591                  ExInts :    11776
+TxErrors   :       0                  SpInts :     1503
+Tx State   :    idle
+
+
+The status info shown is:
+
+Sent		- number of frames transmitted
+Received	- number of frames received
+RxErrors	- number of receive errors (CRC, ABORT)
+TxErrors	- number of discarded Tx frames (due to various reasons) 
+Tx State	- status of the Tx interrupt handler: idle/busy/active/tail (2)
+RxOver		- number of receiver overruns
+TxUnder		- number of transmitter underruns
+RxInts		- number of receiver interrupts
+TxInts		- number of transmitter interrupts
+EpInts		- number of receiver special condition interrupts
+SpInts		- number of external/status interrupts
+Size		- maximum size of an AX.25 frame (*with* AX.25 headers!)
+NoSpace		- number of times a buffer could not get allocated
+
+An overrun is abnormal. If lots of these occur, the product of
+baudrate and number of interfaces is too high for the processing
+power of you computer. NoSpace errors are unlikely caused by the
+driver or the kernel AX.25.
+
+
+3.2 Setting Parameters
+======================
+
+
+The setting of parameters of the emulated KISS TNC is done in the 
+same way in the SCC driver. You can change parameters by using
+the kissparms program from the ax25-utils package or use the program 
+"sccparam":
+
+     sccparam <device> <paramname> <decimal-|hexadecimal value>
+
+You can change the following parameters:
+
+param	    : value
+------------------------
+speed       : 1200
+txdelay     : 36
+persist     : 255
+slottime    : 0
+txtail      : 8
+fulldup     : 1
+waittime    : 12
+mintime     : 3
+maxkeyup    : 7
+idletime    : 3
+maxdefer    : 120
+group       : 0x00
+txoff       : off
+softdcd     : on
+SLIP        : off
+
+
+The parameters have the following meaning:
+
+speed:
+     The baudrate on this channel in bits/sec
+
+     Example: sccparam /dev/scc3 speed 9600
+
+txdelay:
+     The delay (in units of 10ms) after keying of the 
+     transmitter, until the first byte is sent. This is usually 
+     called "TXDELAY" in a TNC.  When 0 is specified, the driver 
+     will just wait until the CTS signal is asserted. This 
+     assumes the presence of a timer or other circuitry in the 
+     MODEM and/or transmitter, that asserts CTS when the 
+     transmitter is ready for data.
+     A normal value of this parameter is 30-36.
+
+     Example: sccparam /dev/scc0 txd 20
+
+persist:
+     This is the probability that the transmitter will be keyed 
+     when the channel is found to be free.  It is a value from 0 
+     to 255, and the probability is (value+1)/256.  The value 
+     should be somewhere near 50-60, and should be lowered when 
+     the channel is used more heavily.
+
+     Example: sccparam /dev/scc2 persist 20
+
+slottime:
+     This is the time between samples of the channel. It is 
+     expressed in units of 10ms.  About 200-300 ms (value 20-30) 
+     seems to be a good value.
+
+     Example: sccparam /dev/scc0 slot 20
+
+tail:
+     The time the transmitter will remain keyed after the last 
+     byte of a packet has been transferred to the SCC. This is 
+     necessary because the CRC and a flag still have to leave the 
+     SCC before the transmitter is keyed down. The value depends 
+     on the baudrate selected.  A few character times should be 
+     sufficient, e.g. 40ms at 1200 baud. (value 4)
+     The value of this parameter is in 10ms units.
+
+     Example: sccparam /dev/scc2 4
+
+full:
+     The full-duplex mode switch. This can be one of the following 
+     values:
+
+     0:   The interface will operate in CSMA mode (the normal 
+          half-duplex packet radio operation)
+     1:   Fullduplex mode, i.e. the transmitter will be keyed at 
+          any time, without checking the received carrier.  It 
+          will be unkeyed when there are no packets to be sent.
+     2:   Like 1, but the transmitter will remain keyed, also 
+          when there are no packets to be sent.  Flags will be 
+          sent in that case, until a timeout (parameter 10) 
+          occurs.
+
+     Example: sccparam /dev/scc0 fulldup off
+
+wait:
+     The initial waittime before any transmit attempt, after the 
+     frame has been queue for transmit.  This is the length of 
+     the first slot in CSMA mode.  In fullduplex modes it is
+     set to 0 for maximum performance.
+     The value of this parameter is in 10ms units. 
+
+     Example: sccparam /dev/scc1 wait 4
+
+maxkey:
+     The maximal time the transmitter will be keyed to send 
+     packets, in seconds.  This can be useful on busy CSMA 
+     channels, to avoid "getting a bad reputation" when you are 
+     generating a lot of traffic.  After the specified time has 
+     elapsed, no new frame will be started. Instead, the trans-
+     mitter will be switched off for a specified time (parameter 
+     min), and then the selected algorithm for keyup will be 
+     started again.
+     The value 0 as well as "off" will disable this feature, 
+     and allow infinite transmission time. 
+
+     Example: sccparam /dev/scc0 maxk 20
+
+min:
+     This is the time the transmitter will be switched off when 
+     the maximum transmission time is exceeded.
+
+     Example: sccparam /dev/scc3 min 10
+
+idle
+     This parameter specifies the maximum idle time in fullduplex 
+     2 mode, in seconds.  When no frames have been sent for this 
+     time, the transmitter will be keyed down.  A value of 0 is
+     has same result as the fullduplex mode 1. This parameter
+     can be disabled.
+
+     Example: sccparam /dev/scc2 idle off	# transmit forever
+
+maxdefer
+     This is the maximum time (in seconds) to wait for a free channel
+     to send. When this timer expires the transmitter will be keyed 
+     IMMEDIATELY. If you love to get trouble with other users you
+     should set this to a very low value ;-)
+
+     Example: sccparam /dev/scc0 maxdefer 240	# 2 minutes
+
+
+txoff:
+     When this parameter has the value 0, the transmission of packets
+     is enable. Otherwise it is disabled.
+
+     Example: sccparam /dev/scc2 txoff on
+
+group:
+     It is possible to build special radio equipment to use more than 
+     one frequency on the same bad, e.g. using several receivers and 
+     only one transmitter that can be switched between frequencies.
+     Also, you can connect several radios that are active on the same 
+     band.  In these cases, it is not possible, or not a good idea, to 
+     transmit on more than one frequency.  The SCC driver provides a 
+     method to lock transmitters on different interfaces, using the 
+     "param <interface> group <x>" command.  This will only work when 
+     you are using CSMA mode (parameter full = 0).
+     The number <x> must be 0 if you want no group restrictions, and 
+     can be computed as follows to create restricted groups:
+     <x> is the sum of some OCTAL numbers:
+
+     200  This transmitter will only be keyed when all other 
+          transmitters in the group are off.
+     100  This transmitter will only be keyed when the carrier 
+          detect of all other interfaces in the group is off.
+     0xx  A byte that can be used to define different groups.  
+          Interfaces are in the same group, when the logical AND 
+          between their xx values is nonzero.
+
+     Examples:
+     When 2 interfaces use group 201, their transmitters will never be 
+     keyed at the same time.
+     When 2 interfaces use group 101, the transmitters will only key 
+     when both channels are clear at the same time.  When group 301, 
+     the transmitters will not be keyed at the same time.
+
+     Don't forget to convert the octal numbers into decimal before
+     you set the parameter.
+
+     Example: (to be written)
+
+softdcd:
+     use a software dcd instead of the real one... Useful for a very
+     slow squelch.
+
+     Example: sccparam /dev/scc0 soft on
+
+
+4. Problems 
+===========
+
+If you have tx-problems with your BayCom USCC card please check
+the manufacturer of the 8530. SGS chips have a slightly
+different timing. Try Zilog...  A solution is to write to register 8 
+instead to the data port, but this won't work with the ESCC chips. 
+*SIGH!*
+
+A very common problem is that the PTT locks until the maxkeyup timer
+expires, although interrupts and clock source are correct. In most
+cases #define SCC_DELAY solves the problems. For more hints read
+the (pseudo) FAQ and the documentation coming with z8530drv-utils.
+
+I got reports that the driver has problems on some 386-based systems.
+(i.e. Amstrad) Those systems have a bogus AT bus timing which will
+lead to delayed answers on interrupts. You can recognize these
+problems by looking at the output of Sccstat for the suspected
+port. See if it shows under- and overruns you own such a system.
+
+Delayed processing of received data: This depends on
+
+- the kernel version
+
+- kernel profiling compiled or not
+
+- a high interrupt load
+
+- a high load of the machine --- running X, Xmorph, XV and Povray,
+  while compiling the kernel... hmm ... even with 32 MB RAM ...  ;-)
+  Or running a named for the whole .ampr.org. domain on an 8 MB
+  box...
+
+- using information from rxecho or kissbridge.
+
+Kernel panics: please read to /linux/README and find out if it
+really occurred within the scc driver.
+
+If you cannot solve a problem, send me
+
+- a description of the problem,
+- information on your hardware (computer system, scc board, modem)
+- your kernel version
+- the output of cat /proc/net/z8530
+
+4. Thor RLC100
+==============
+
+Mysteriously this board seems not to work with the driver. Anyone
+got it up-and-running?
+
+
+Many thanks to Linus Torvalds and Alan Cox for including the driver
+in the Linux standard distribution and their support.
+
+Joerg Reuter	ampr-net: dl1bke@db0pra.ampr.org
+		AX-25   : DL1BKE @ DB0ACH.#NRW.DEU.EU
+		Internet: jreuter@lykos.oche.de
diff --git a/Documentation/nfsroot.txt b/Documentation/nfsroot.txt
new file mode 100644
index 000000000..43d79a89b
--- /dev/null
+++ b/Documentation/nfsroot.txt
@@ -0,0 +1,204 @@
+Mounting the root filesystem via NFS (nfsroot)
+==============================================
+
+Written 1996 by Gero Kuhlmann <gero@gkminix.han.de>
+
+
+
+If you want to use a diskless system, as an X-terminal or printer
+server for example, you have to put your root filesystem onto a
+non-disk device. This can either be a ramdisk (see initrd.txt in
+this directory for further information) or a filesystem mounted
+via NFS. The following text describes on how to use NFS for the
+root filesystem. For the rest of this text 'client' means the
+diskless system, and 'server' means the NFS server.
+
+
+
+
+1.) Enabling nfsroot capabilities
+    -----------------------------
+
+In order to use nfsroot you have to select support for NFS during
+kernel configuration. Note that NFS cannot be loaded as a module
+in this case. The configuration script will then ask you whether
+you want to use nfsroot, and if yes what kind of auto configuration
+system you want to use. Selecting both BOOTP and RARP is safe.
+
+
+
+
+2.) Kernel command line
+    -------------------
+
+When the kernel has been loaded by a boot loader (either by loadlin,
+LILO or a network boot program) it has to be told what root fs device
+to use, and where to find the server and the name of the directory
+on the server to mount as root. This can be established by a couple
+of kernel command line parameters:
+
+
+root=/dev/nfs
+
+  This is necessary to enable the pseudo-NFS-device. Note that it's not a
+  real device but just a synonym to tell the kernel to use NFS instead of
+  a real device.
+
+
+nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
+
+  If the nfsroot parameter is NOT give on the command line, the default
+  "/tftpboot/%s" will be used.
+
+  <server-ip>	Specifies the IP address of the NFS server. If this field
+		is not given, the default address as determined by the
+		nfsaddrs variable (see below) is used. One use of this
+		parameter is for example to allow using different servers
+		for RARP and NFS. Usually you can leave this blank.
+
+  <root-dir>	Name of the directory on the server to mount as root. If
+		there is a "%s" token in the string, the token will be
+		replaced by the ASCII-representation of the client's IP
+		address.
+
+  <nfs-options>	Standard NFS options. All options are separated by commas.
+		If the options field is not given, the following defaults
+		will be used:
+			port		= as given by server portmap daemon
+			rsize		= 1024
+			wsize		= 1024
+			timeo		= 7
+			retrans		= 3
+			acregmin	= 3
+			acregmax	= 60
+			acdirmin	= 30
+			acdirmax	= 60
+			flags		= hard, nointr, noposix, cto, ac
+
+
+nfsaddrs=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
+
+  If this parameter is missing on the kernel command line, all fields are
+  assumed to be empty, and the below mentioned defaults apply. In general
+  this means that the kernel tries to configure everything using both
+  RARP and BOOTP (depending on what has been enabled during kernel confi-
+  guration, and if both what protocol answer got in first).
+
+  <client-ip>	IP address of the client. If empty, the address will either
+		be determined by RARP or BOOTP. What protocol is used de-
+		pends on what has been enabled during kernel configuration
+		and on the <autoconf> parameter. If this parameter is not
+		empty, neither RARP nor BOOTP will be used.
+
+  <server-ip>	IP address of the NFS server. If RARP is used to determine
+		the client address and this parameter is NOT empty only
+		replies from the specified server are accepted. To use
+		different RARP and NFS server, specify your RARP server
+		here (or leave it blank), and specify your NFS server in
+		the nfsroot parameter (see above). If this entry is blank
+		the address of the server is used which answered the RARP
+		or BOOTP request.
+
+  <gw-ip>	IP address of a gateway if the server in on a different
+		subnet. If this entry is empty no gateway is used and the
+		server is assumed to be on the local network, unless a
+		value has been received by BOOTP.
+
+  <netmask>	Netmask for local network interface. If this is empty,
+		the netmask is derived from the client IP address, un-
+		less a value has been received by BOOTP.
+
+  <hostname>	Name of the client. If empty, the client IP address is
+		used in ASCII-notation, or the value received by BOOTP.
+
+  <device>	Name of network device to use. If this is empty, all
+		devices are used for RARP requests, and the first one
+		found for BOOTP. For NFS the device is used on which
+		either RARP or BOOTP replies have been received. If
+		you only have one device you can safely leave this blank.
+
+  <autoconf>	Method to use for autoconfiguration. If this is either
+		'rarp' or 'bootp' the specified protocol is being used.
+		If the value is 'both' or empty, both protocols are used
+		so far as they have been enabled during kernel configura-
+		tion. 'none' means no autoconfiguration. In this case you
+		have to specify all necessary values in the fields before.
+
+  The <autoconf> parameter can appear alone as the value to the nfsaddrs
+  parameter (without all the ':' characters before) in which case auto-
+  configuration is used. However, the 'none' value is not available in
+  that case.
+
+
+
+
+3.) Kernel loader
+    -------------
+
+To get the kernel into memory different approaches can be used. They
+depend on what facilities are available:
+
+
+3.1)  Writing the kernel onto a floppy using dd:
+	As always you can just write the kernel onto a floppy using dd,
+	but then it's not possible to use kernel command lines at all.
+	To substitute the 'root=' parameter, create a dummy device on any
+	linux system with major number 0 and minor number 255 using mknod:
+
+		mknod /dev/boot255 c 0 255
+
+	Then copy the kernel zImage file onto a floppy using dd:
+
+		dd if=/usr/src/linux/arch/i386/boot/zImage of=/dev/fd0
+
+	And finally use rdev to set the root device:
+
+		rdev /dev/fd0 /dev/boot255
+
+	You can then remove the dummy device /dev/boot255 again. There
+	is no real device available for it.
+	The other two kernel command line parameters cannot be substi-
+	tuted with rdev. Therefore, using this method the kernel will
+	by default use RARP and/or BOOTP, and if it gets an answer via
+	RARP will mount the directory /tftpboot/<client-ip>/ as its
+	root. If it got a BOOTP answer the directory name in that answer
+	is used.
+
+
+3.2) Using LILO
+	When using LILO you can specify all necessary command line
+	parameters with the 'append=' command in the LILO configuration
+	file. However, to use the 'root=' command you also need to
+	set up a dummy device as described in 3.1 above. For how to use
+	LILO and its 'append=' command please refer to the LILO
+	documentation.
+
+3.3) Using loadlin
+	When you want to boot Linux from a DOS command prompt without
+	having a local hard disk to mount as root, you can use loadlin.
+	I was told that it works, but haven't used it myself yet. In
+	general you should be able to create a kernel command line simi-
+	lar to how LILO is doing it. Please refer to the loadlin docu-
+	mentation for further information.
+
+3.4) Using a bootrom
+	This is probably the most elegant way of booting a diskless
+	client. With a bootrom the kernel gets loaded using the TFTP
+	protocol. As far as I know no commercial bootroms already
+	support booting Linux over the network, but there are two
+	free implementations of a bootrom available on sunsite.unc.edu
+	and its mirrors. They are called 'netboot-nfs' and 'etherboot'.
+	Both contain everything you need to boot a diskless Linux client.
+
+
+
+
+4.) Credits
+    -------
+
+  The nfsroot code in the kernel has been written by me, Gero Kuhlmann
+  <gero@gkminix.han.de>, with the BOOTP code and a couple of bug fixes
+  contributed by Martin Mares <mj@k332.feld.cvut.cz>. In order to write
+  the initial version of nfsroot I would like to thank Jens-Uwe Mager
+  <jum@anubis.han.de> for his help.
+
diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt
new file mode 100644
index 000000000..2fb21a726
--- /dev/null
+++ b/Documentation/oops-tracing.txt
@@ -0,0 +1,150 @@
+From: Linus Torvalds <torvalds@cs.helsinki.fi>
+
+How to track down an Oops.. [originally a mail to linux-kernel]
+
+The main trick is having 5 years of experience with those pesky oops 
+messages ;-)
+
+Actually, there are things you can do that make this easier. I have two 
+separate approaches:
+
+	gdb /usr/src/linux/vmlinux
+	gdb> disassemble <offending_function>
+
+That's the easy way to find the problem, at least if the bug-report is 
+well made (like this one was - run through ksymoops to get the 
+information of which function and the offset in the function that it 
+happened in).
+
+Oh, it helps if the report happens on a kernel that is compiled with the 
+same compiler and similar setups.
+
+The other thing to do is disassemble the "Code:" part of the bug report: 
+ksymoops will do this too with the correct tools (and new version of 
+ksymoops), but if you don't have the tools you can just do a silly 
+program:
+
+	char str[] = "\xXX\xXX\xXX...";
+	main(){}
+
+and compile it with gcc -g and then do "disassemble str" (where the "XX" 
+stuff are the values reported by the Oops - you can just cut-and-paste 
+and do a replace of spaces to "\x" - that's what I do, as I'm too lazy 
+to write a program to automate this all).
+
+Finally, if you want to see where the code comes from, you can do
+
+	cd /usr/src/linux
+	make fs/buffer.s 	# or whatever file the bug happened in
+
+and then you get a better idea of what happens than with the gdb 
+disassembly.
+
+Now, the trick is just then to combine all the data you have: the C 
+sources (and general knowledge of what it _should_ do, the assembly 
+listing and the code disassembly (and additionally the register dump you 
+also get from the "oops" message - that can be useful to see _what_ the 
+corrupted pointers were, and when you have the assembler listing you can 
+also match the other registers to whatever C expressions they were used 
+for).
+
+Essentially, you just look at what doesn't match (in this case it was the 
+"Code" disassembly that didn't match with what the compiler generated). 
+Then you need to find out _why_ they don't match. Often it's simple - you 
+see that the code uses a NULL pointer and then you look at the code and 
+wonder how the NULL pointer got there, and if it's a valid thing to do 
+you just check against it..
+
+Now, if somebody gets the idea that this is time-consuming and requires 
+some small amount of concentration, you're right. Which is why I will 
+mostly just ignore any panic reports that don't have the symbol table 
+info etc looked up: it simply gets too hard to look it up (I have some 
+programs to search for specific patterns in the kernel code segment, and 
+sometimes I have been able to look up those kinds of panics too, but 
+that really requires pretty good knowledge of the kernel just to be able 
+to pick out the right sequences etc..)
+
+_Sometimes_ it happens that I just see the disassembled code sequence 
+from the panic, and I know immediately where it's coming from. That's when 
+I get worried that I've been doing this for too long ;-)
+
+		Linus
+
+
+---------------------------------------------------------------------------
+Notes on Oops tracing with klogd:
+
+In order to help Linus and the other kernel developers there has been
+substantial support incorporated into klogd for processing protection
+faults.  In order to have full support for address resolution at least
+version 1.3-pl3 of the sysklogd package should be used.
+
+When a protection fault occurs the klogd daemon automatically
+translates important addresses in the kernel log messages to their
+symbolic equivalents.  This translated kernel message is then
+forwarded through whatever reporting mechanism klogd is using.  The
+protection fault message can be simply cut out of the message files
+and forwarded to the kernel developers.
+
+Two types of address resolution are performed by klogd.  The first is
+static translation and the second is dynamic translation.  Static
+translation uses the System.map file in much the same manner that
+ksymoops does.  In order to do static translation the klogd daemon
+must be able to find a system map file at daemon initialization time.
+See the klogd man page for information on how klogd searches for map
+files.
+
+Dynamic address translation is important when kernel loadable modules
+are being used.  Since memory for kernel modules is allocated from the
+kernel's dynamic memory pools there are no fixed locations for either
+the start of the module or for functions and symbols in the module.
+
+The kernel supports system calls which allow a program to determine
+which modules are loaded and their location in memory.  Using these
+system calls the klogd daemon builds a symbol table which can be used
+to debug a protection fault which occurs in a loadable kernel module.
+
+At the very minimum klogd will provide the name of the module which
+generated the protection fault.  There may be additional symbolic
+information available if the developer of the loadable module chose to
+export symbol information from the module.
+
+Since the kernel module environment can be dynamic there must be a
+mechanism for notifying the klogd daemon when a change in module
+environment occurs.  There are command line options available which
+allow klogd to signal the currently executing daemon that symbol
+information should be refreshed.  See the klogd manual page for more
+information.
+
+A patch is included with the sysklogd distribution which modifies the
+modules-2.0.0 package to automatically signal klogd whenever a module
+is loaded or unloaded.  Applying this patch provides essentially
+seamless support for debugging protection faults which occur with
+kernel loadable modules.
+
+The following is an example of a protection fault in a loadable module
+processed by klogd:
+---------------------------------------------------------------------------
+Aug 29 09:51:01 blizard kernel: Unable to handle kernel paging request at virtual address f15e97cc
+Aug 29 09:51:01 blizard kernel: current->tss.cr3 = 0062d000, %cr3 = 0062d000
+Aug 29 09:51:01 blizard kernel: *pde = 00000000
+Aug 29 09:51:01 blizard kernel: Oops: 0002
+Aug 29 09:51:01 blizard kernel: CPU:    0
+Aug 29 09:51:01 blizard kernel: EIP:    0010:[oops:_oops+16/3868]
+Aug 29 09:51:01 blizard kernel: EFLAGS: 00010212
+Aug 29 09:51:01 blizard kernel: eax: 315e97cc   ebx: 003a6f80   ecx: 001be77b   edx: 00237c0c
+Aug 29 09:51:01 blizard kernel: esi: 00000000   edi: bffffdb3   ebp: 00589f90   esp: 00589f8c
+Aug 29 09:51:01 blizard kernel: ds: 0018   es: 0018   fs: 002b   gs: 002b   ss: 0018
+Aug 29 09:51:01 blizard kernel: Process oops_test (pid: 3374, process nr: 21, stackpage=00589000)
+Aug 29 09:51:01 blizard kernel: Stack: 315e97cc 00589f98 0100b0b4 bffffed4 0012e38e 00240c64 003a6f80 00000001 
+Aug 29 09:51:01 blizard kernel:        00000000 00237810 bfffff00 0010a7fa 00000003 00000001 00000000 bfffff00 
+Aug 29 09:51:01 blizard kernel:        bffffdb3 bffffed4 ffffffda 0000002b 0007002b 0000002b 0000002b 00000036 
+Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128] 
+Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3 
+---------------------------------------------------------------------------
+
+Dr. G.W. Wettstein           Oncology Research Div. Computing Facility
+Roger Maris Cancer Center    INTERNET: greg@wind.rmcc.com
+820 4th St. N.
+Fargo, ND  58122
+Phone: 701-234-7556
diff --git a/Documentation/ramdisk.txt b/Documentation/ramdisk.txt
new file mode 100644
index 000000000..5b48c3987
--- /dev/null
+++ b/Documentation/ramdisk.txt
@@ -0,0 +1,207 @@
+
+Using the RAM disk block device with Linux
+------------------------------------------
+
+Contents:
+
+	1) Overview
+	2) Kernel Command Line Parameters
+	3) Using "rdev -r" With New Kernels
+	4) An Example of Creating a Compressed ramdisk 
+
+
+1) Overview
+-----------
+
+As of kernel v1.3.48, the ramdisk driver was substantially changed.
+
+The older versions would grab a chunk of memory off the top before
+handing the remainder to the kernel at boot time. Thus a size parameter
+had to be specified via "ramdisk=1440" or "rdev -r /dev/fd0 1440" so
+that the driver knew how much memory to grab.
+
+Now the ramdisk dynamically grows as more space is required. It does
+this by using RAM from the buffer cache. The driver marks the buffers
+it is using with a new "BH_Protected" flag so that the kernel does 
+not try to reuse them later. This means that the old size parameter
+is no longer used, new command line parameters exist, and the behavior
+of the "rdev -r" or "ramsize" (usually a symbolic link to "rdev")
+command has changed.
+
+Also, the new ramdisk supports up to 16 ramdisks out of the box, and can
+be reconfigured in rd.c to support up to 255 ramdisks.  To use multiple
+ramdisk support with your system, run 'mknod /dev/ramX b 1 X' and chmod
+(to change it's permissions) it to your liking.  The default /dev/ram(disk)
+uses minor #1, so start with ram2 and go from there.
+
+The old "ramdisk=<ram_size>" has been changed to "ramdisk_size=<ram_size>"
+to make it clearer.  The original "ramdisk=<ram_size>" has been kept around
+for compatibility reasons, but it will probably be removed in 2.1.x.
+
+The new ramdisk also has the ability to load compressed ramdisk images,
+allowing one to squeeze more programs onto an average installation or 
+rescue floppy disk.
+
+Notes: You may have "dev/ram" or "/dev/ramdisk" or both. They are
+equivalent from the standpoint of this document. Also, the new ramdisk
+is a config option. When running "make config", make sure you enable
+ramdisk support for the kernel you intend to use the ramdisk with.
+
+
+2) Kernel Command Line Parameters
+---------------------------------
+
+	ramdisk_start=NNN
+	=================
+
+To allow a kernel image to reside on a floppy disk along with a compressed
+ramdisk image, the "ramdisk_start=<offset>" command was added. The kernel
+can't be included into the compressed ramdisk filesystem image, because
+it needs to be stored starting at block zero so that the BIOS can load the 
+bootsector and then the kernel can bootstrap itself to get going.
+
+Note: If you are using an uncompressed ramdisk image, then the kernel can
+be a part of the filesystem image that is being loaded into the ramdisk,
+and the floppy can be booted with LILO, or the two can be separate as
+is done for the compressed images.
+
+If you are using a two-disk boot/root setup (kernel on #1, ramdisk image
+on #2) then the ramdisk would start at block zero, and an offset of
+zero would be used. Since this is the default value, you would not need
+to actually use the command at all.
+
+If instead, you have a "zImage" of about 350k, and a "fs_image.gz" of
+say about 1MB, and you want them both on the same disk, then you
+would use an offset. If you stored the "fs_image.gz" onto the floppy
+starting at an offset of 400kB, you would use "ramdisk_start=400".
+
+
+	load_ramdisk=N
+	==============
+
+This parameter tells the kernel whether it is to try to load a
+ramdisk image or not. Specifying "load_ramdisk=1" will tell the
+kernel to load a floppy into the ramdisk. The default value is
+zero, meaning that the kernel should not try to load a ramdisk.
+
+
+	prompt_ramdisk=N
+	================
+
+This parameter tells the kernel whether or not to give you a prompt
+asking you to insert the floppy containing the ramdisk image. In
+a single floppy configuration the ramdisk image is on the same floppy
+as the kernel that just finished loading/booting and so a prompt
+is not needed. In this case one can use "prompt_ramdisk=0". In a
+two floppy configuration, you will need the chance to switch disks,
+and thus "prompt_ramdisk=1" can be used. Since this is the default 
+value, it doesn't really need to be specified.
+
+	ramdisk_size=N
+	==============
+
+This parameter tells the ramdisk driver to set up ramdisks of Nk size.  The
+default is 4096 (4MB). 
+
+3) Using "rdev -r" With New Kernels
+-----------------------------------
+
+The usage of the word (two bytes) that "rdev -r" sets in the kernel image
+has changed. The low 11 bits (0 -> 10) specify an offset (in 1k blocks) 
+of up to 2MB (2^11) of where to find the ramdisk (this used to be the 
+size). Bit 14 indicates that a ramdisk is to be loaded, and bit 15
+indicates whether a prompt/wait sequence is to be given before trying
+to read the ramdisk. Since the ramdisk dynamically grows as data is
+being written into it, a size field is no longer required. Bits 11
+to 13 are not presently used and may as well be zero. These numbers
+are no magical secrets, as seen below:
+
+./arch/i386/kernel/setup.c:#define RAMDISK_IMAGE_START_MASK     0x07FF
+./arch/i386/kernel/setup.c:#define RAMDISK_PROMPT_FLAG          0x8000
+./arch/i386/kernel/setup.c:#define RAMDISK_LOAD_FLAG            0x4000
+
+Consider a typical two floppy disk setup, where you will have the 
+kernel on disk one, and have already put a ramdisk image onto disk #2.
+
+Hence you want to set bits 0 to 13 as zero, meaning that your ramdisk
+starts at an offset of zero kB from the beginning of the floppy.
+The command line equivalent is: "ramdisk_start=0"
+
+You want bit 14 as one, indicating that a ramdisk is to be loaded.
+The command line equivalent is: "load_ramdisk=1"
+
+You want bit 15 as one, indicating that you want a prompt/keypress
+sequence so that you have a chance to switch floppy disks.
+The command line equivalent is: "prompt_ramdisk=1"
+
+Putting that together gives 2^15 + 2^14 + 0 = 49152 for an rdev word.
+So to create disk one of the set, you would do:
+
+	/usr/src/linux# cat arch/i386/boot/zImage > /dev/fd0
+	/usr/src/linux# rdev /dev/fd0 /dev/fd0
+	/usr/src/linux# rdev -r /dev/fd0 49152
+
+If you make a boot disk that has LILO, then for the above, you would use:
+	append = "ramdisk_start=0 load_ramdisk=1 prompt_ramdisk=1"
+Since the default start = 0 and the default prompt = 1, you could use:
+	append = "load_ramdisk=1"
+
+
+4) An Example of Creating a Compressed ramdisk 
+----------------------------------------------
+
+To create a ramdisk image, you will need a spare block device to
+construct it on. This can be the ramdisk device itself, or an
+unused disk partition (such as an unmounted swap partition). For this 
+example, we will use the ramdisk device, "/dev/ram".
+
+Note: This technique should not be done on a machine with less than 8MB
+of RAM. If using a spare disk partition instead of /dev/ram, then this
+restriction does not apply.
+
+a) Decide on the ramdisk size that you want. Say 2MB for this example.
+   Create it by writing to the ramdisk device. (This step is not presently
+   required, but may be in the future.) It is wise to zero out the
+   area (esp. for disks) so that maximal compression is achieved for
+   the unused blocks of the image that you are about to create.
+
+	dd if=/dev/zero of=/dev/ram bs=1k count=2048
+
+b) Make a filesystem on it. Say ext2fs for this example.
+
+	mke2fs -vm0 /dev/ram 2048
+
+c) Mount it, copy the files you want to it (eg: /etc/* /dev/* ...)
+   and unmount it again.
+
+d) Compress the contents of the ramdisk. The level of compression
+   will be approximately 50% of the space used by the files. Unused
+   space on the ramdisk will compress to almost nothing.
+
+	dd if=/dev/ram bs=1k count=2048 | gzip -v9 > /tmp/ram_image.gz
+
+e) Put the kernel onto the floppy
+
+	dd if=zImage of=/dev/fd0 bs=1k
+
+f) Put the ramdisk image onto the floppy, after the kernel. Use an offset
+   that is slightly larger than the kernel, so that you can put another
+   (possibly larger) kernel onto the same floppy later without overlapping
+   the ramdisk image. An offset of 400kB for kernels about 350kB in
+   size would be reasonable. Make sure offset+size of ram_image.gz is
+   not larger than the total space on your floppy (usually 1440kB).
+
+	dd if=/tmp/ram_image.gz of=/dev/fd0 bs=1k seek=400
+
+g) Use "rdev" to set the boot device, ramdisk offset, prompt flag, etc.
+   For prompt_ramdisk=1, load_ramdisk=1, ramdisk_start=400, one would
+   have 2^15 + 2^14 + 400 = 49552.
+
+	rdev /dev/fd0 /dev/fd0
+	rdev -r /dev/fd0 49552
+
+That is it. You now have your boot/root compressed ramdisk floppy. Some
+users may wish to combine steps (d) and (f) by using a pipe.
+
+--------------------------------------------------------------------------
+						Paul Gortmaker 12/95	
diff --git a/Documentation/riscom8.txt b/Documentation/riscom8.txt
new file mode 100644
index 000000000..6157bb11d
--- /dev/null
+++ b/Documentation/riscom8.txt
@@ -0,0 +1,56 @@
+	This is the README for RISCom/8 multi-port serial driver
+	(C) 1994-1996 D.Gorodchanin (begemot@bgm.rosrpint.net)
+	See file LICENSE for terms and conditions.
+
+NOTE: English is not my native language. 
+      I'm sorry for any mistakes in this text.
+
+Misc. notes for RISCom/8 serial driver, in no particular order :)
+
+1) This driver can support up to 4 boards at time.
+   Use string "riscom8=0xXXX,0xXXX,0xXXX,0xXXX" at LILO prompt, for
+   setting I/O base addresses for boards. If you compile driver
+   as module use insmod options "iobase=0xXXX iobase1=0xXXX iobase2=..."
+
+2) The driver partially supports famous 'setserial' program, you can use almost
+   any it option, exclude port & irq settings.
+
+3) There are some misc. defines at the beginning of riscom8.c, please read the 
+   comments and try to change some of them in case of problems.
+	
+4) I consider the current state of the driver as BETA.
+   If you REALLY think you found the bug, send me e-mail, I hope I'll
+   fix it. For any other problems please ask support@sdlcomm.com.
+
+5) SDL Communications WWW page is http://www.sdlcomm.com.
+
+6) You can use the script at the end of this file to create RISCom/8 devices.
+
+7) Minors number for 1-st board are 0-7, for second 8-15, etc.
+
+22 Apr 1996.
+
+-------------------------------cut here-------------------------------------
+#!/bin/bash
+NORMAL_DEVICE=/dev/ttyL
+CALLOUT_DEVICE=/dev/cuL
+NORMAL_MAJOR=48
+CALLOUT_MAJOR=49
+
+echo "Creating devices... "
+for i in 0 1 2 3; do
+	echo "Board No $[$i+1]"
+	for j in 0 1 2 3 4 5 6 7; do
+		k=$[ 8 * $i + $j]
+		rm -f $NORMAL_DEVICE$k 
+		mknod $NORMAL_DEVICE$k c $NORMAL_MAJOR $k
+		chmod a+rw $NORMAL_DEVICE$k
+		echo -n $NORMAL_DEVICE$k" "
+		rm -f $CALLOUT_DEVICE$k 
+		mknod $CALLOUT_DEVICE$k c $CALLOUT_MAJOR $k
+		chmod a+rw $CALLOUT_DEVICE$k
+		echo $CALLOUT_DEVICE$k
+	done
+done
+echo "done."
+-------------------------------cut here-------------------------------------
diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt
new file mode 100644
index 000000000..e290b4177
--- /dev/null
+++ b/Documentation/rtc.txt
@@ -0,0 +1,281 @@
+
+	Real Time Clock Driver for Linux
+	================================
+
+All PCs (even Alpha machines) have a Real Time Clock built into them.
+Usually they are built into the chipset of the computer, but some may
+actually have a Motorola MC146818 (or clone) on the board. This is the
+clock that keeps the date and time while your computer is turned off.
+
+However it can also be used to generate signals from a slow 2Hz to a
+relatively fast 8192Hz, in increments of powers of two. These signals
+are reported by interrupt number 8. (Oh! So *that* is what IRQ 8 is
+for...) It can also function as a 24hr alarm, raising IRQ 8 when the
+alarm goes off. The alarm can also be programmed to only check any
+subset of the three programmable values, meaning that it could be set to
+ring on the 30th second of the 30th minute of every hour, for example.
+The clock can also be set to generate an interrupt upon every clock
+update, thus generating a 1Hz signal.
+
+The interrupts are reported via /dev/rtc (major 10, minor 135, read only
+character device) in the form of an unsigned long. The low byte contains
+the type of interrupt (update-done, alarm-rang, or periodic) that was
+raised, and the remaining bytes contain the number of interrupts since
+the last read.  Status information is reported through the pseudo-file
+/proc/rtc if the /proc filesystem was enabled. The driver has built in
+locking so that only one process is allowed to have the /dev/rtc
+interface open at a time.
+
+A user process can monitor these interrupts by doing a read(2) or a
+select(2) on /dev/rtc -- either will block/stop the user process until
+the next interrupt is received. This is useful for things like
+reasonably high frequency data acquisition where one doesn't want to
+burn up 100% CPU by polling gettimeofday etc. etc.
+
+At high frequencies, or under high loads, the user process should check
+the number of interrupts received since the last read to determine if
+there has been any interrupt "pileup" so to speak. Just for reference, a
+typical 486-33 running a tight read loop on /dev/rtc will start to suffer
+occasional interrupt pileup (i.e. > 1 IRQ event since last read) for
+frequencies above 1024Hz. So you really should check the high bytes
+of the value you read, especially at frequencies above that of the
+normal timer interrupt, which is 100Hz.
+
+Programming and/or enabling interrupt frequencies greater than 64Hz is
+only allowed by root. This is perhaps a bit conservative, but we don't want
+an evil user generating lots of IRQs on a slow 386sx-16, where it might have
+a negative impact on performance.  Note that the interrupt handler is only
+a few lines of code to minimize any possibility of this effect.
+
+Also, if the kernel time is synchronized with an external source, the 
+kernel will write the time back to the CMOS clock every 11 minutes. In 
+the process of doing this, the kernel briefly turns off RTC periodic 
+interrupts, so be aware of this if you are doing serious work. If you
+don't synchronize the kernel time with an external source (via ntp or
+whatever) then the kernel will keep its hands off the RTC, allowing you
+exclusive access to the device for your applications.
+
+The alarm and/or interrupt frequency are programmed into the RTC via
+various ioctl(2) calls as listed in ./include/linux/mc146818rtc.h
+Rather than write 50 pages describing the ioctl() and so on, it is
+perhaps more useful to include a small test program that demonstrates
+how to use them, and demonstrates the features of the driver. This is
+probably a lot more useful to people interested in writing applications
+that will be using this driver.
+
+						Paul Gortmaker
+
+-------------------- 8< ---------------- 8< -----------------------------
+
+/*
+ *	Real Time Clock Driver Test/Example Program
+ *
+ *	Compile with:
+ *		gcc -s -Wall -Wstrict-prototypes rtctest.c -o rtctest
+ *
+ *	Copyright (C) 1996, Paul Gortmaker.
+ *
+ *	Released under the GNU General Public License, version 2,
+ *	included herein by reference.
+ *
+ */
+
+#include <stdio.h>
+#include <linux/mc146818rtc.h>
+#include <sys/ioctl.h>
+#include <sys/time.h>
+#include <sys/types.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <errno.h>
+
+void main(void) {
+
+int i, fd, retval, irqcount = 0;
+unsigned long tmp, data;
+struct rtc_time rtc_tm;
+
+fd = open ("/dev/rtc", O_RDONLY);
+
+if (fd ==  -1) {
+	perror("/dev/rtc");
+	exit(errno);
+}
+
+fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");
+
+/* Turn on update interrupts (one per second) */
+retval = ioctl(fd, RTC_UIE_ON, 0);
+if (retval == -1) {
+	perror("ioctl");
+	exit(errno);
+}
+
+fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading /dev/rtc:");
+fflush(stderr);
+for (i=1; i<6; i++) {
+	/* This read will block */
+	retval = read(fd, &data, sizeof(unsigned long));
+	if (retval == -1) {
+		perror("read");
+		exit(errno);
+	}
+	fprintf(stderr, " %d",i);
+	fflush(stderr);
+	irqcount++;
+}
+
+fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:");
+fflush(stderr);
+for (i=1; i<6; i++) {
+	struct timeval tv = {5, 0};	/* 5 second timeout on select */
+	struct fd_set readfds;
+
+	FD_ZERO(&readfds);
+	FD_SET(fd, &readfds);
+	/* The select will wait until an RTC interrupt happens. */
+	retval = select(fd+1, &readfds, NULL, NULL, &tv);
+	if (retval == -1) {
+		perror("select");
+		exit(errno);
+	}
+	/* This read won't block unlike the select-less case above. */
+	retval = read(fd, &data, sizeof(unsigned long));
+	if (retval == -1) {
+		perror("read");
+		exit(errno);
+	}
+	fprintf(stderr, " %d",i);
+	fflush(stderr);
+	irqcount++;
+}
+
+/* Turn off update interrupts */
+retval = ioctl(fd, RTC_UIE_OFF, 0);
+if (retval == -1) {
+	perror("ioctl");
+	exit(errno);
+}
+
+/* Read the RTC time/date */
+retval = ioctl(fd, RTC_RD_TIME, &rtc_tm);
+if (retval == -1) {
+	perror("ioctl");
+	exit(errno);
+}
+
+fprintf(stderr, "\n\nCurrent RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n",
+	rtc_tm.tm_mday, rtc_tm.tm_mon + 1, rtc_tm.tm_year + 1900,
+	rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
+
+/* Set the alarm to 5 sec in the future, and check for rollover */
+rtc_tm.tm_sec += 5;
+if (rtc_tm.tm_sec >= 60) {
+	rtc_tm.tm_sec %= 60;
+	rtc_tm.tm_min++;
+}
+if  (rtc_tm.tm_min == 60) {
+	rtc_tm.tm_min = 0;
+	rtc_tm.tm_hour++;
+}
+if  (rtc_tm.tm_hour == 24)
+	rtc_tm.tm_hour = 0;
+
+retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
+if (retval == -1) {
+	perror("ioctl");
+	exit(errno);
+}
+
+/* Read the current alarm settings */
+retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
+if (retval == -1) {
+	perror("ioctl");
+	exit(errno);
+}
+
+fprintf(stderr, "Alarm time now set to %02d:%02d:%02d.\n",
+	rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
+
+/* Enable alarm interrupts */
+retval = ioctl(fd, RTC_AIE_ON, 0);
+if (retval == -1) {
+	perror("ioctl");
+	exit(errno);
+}
+
+fprintf(stderr, "Waiting 5 seconds for alarm...");
+fflush(stderr);
+/* This blocks until the alarm ring causes an interrupt */
+retval = read(fd, &data, sizeof(unsigned long));
+if (retval == -1) {
+	perror("read");
+	exit(errno);
+}
+irqcount++;
+fprintf(stderr, " okay. Alarm rang.\n");
+
+/* Disable alarm interrupts */
+retval = ioctl(fd, RTC_AIE_OFF, 0);
+if (retval == -1) {
+	perror("ioctl");
+	exit(errno);
+}
+
+/* Read periodic IRQ rate */
+retval = ioctl(fd, RTC_IRQP_READ, &tmp);
+if (retval == -1) {
+	perror("ioctl");
+	exit(errno);
+}
+fprintf(stderr, "\nPeriodic IRQ rate was %ldHz.\n", tmp);
+
+fprintf(stderr, "Counting 20 interrupts at:");
+fflush(stderr);
+
+/* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */
+for (tmp=2; tmp<=64; tmp*=2) {
+
+	retval = ioctl(fd, RTC_IRQP_SET, tmp);
+	if (retval == -1) {
+		perror("ioctl");
+		exit(errno);
+	}
+
+	fprintf(stderr, "\n%ldHz:\t", tmp);
+	fflush(stderr);
+
+	/* Enable periodic interrupts */
+	retval = ioctl(fd, RTC_PIE_ON, 0);
+	if (retval == -1) {
+		perror("ioctl");
+		exit(errno);
+	}
+
+	for (i=1; i<21; i++) {
+		/* This blocks */
+		retval = read(fd, &data, sizeof(unsigned long));
+		if (retval == -1) {
+			perror("read");
+			exit(errno);
+		}
+		fprintf(stderr, " %d",i);
+		fflush(stderr);
+		irqcount++;
+	}
+
+	/* Disable periodic interrupts */
+	retval = ioctl(fd, RTC_PIE_OFF, 0);
+	if (retval == -1) {
+		perror("ioctl");
+		exit(errno);
+	}
+}
+
+fprintf(stderr, "\n\n\t\t\t *** Test complete ***\n");
+fprintf(stderr, "\nTyping \"cat /proc/interrupts\" will show %d more events on IRQ 8.\n\n",
+								 irqcount);
+
+close(fd);
+
+} /* end main */
diff --git a/Documentation/scsi.txt b/Documentation/scsi.txt
new file mode 100644
index 000000000..1ce285f06
--- /dev/null
+++ b/Documentation/scsi.txt
@@ -0,0 +1,30 @@
+
+	The scsi support in the linux kernel can be modularized in a
+number of different ways depending upon the needs of the end user.  To
+understand  your options, we should first define a few terms.
+
+	The scsi-core contains the core of scsi support.  Without it
+you can do nothing with any of the other scsi drivers.  The scsi core
+support can be a module (scsi_mod.o), or it can be build into the kernel.
+If the core is a module, it must be the first scsi module loaded, and
+if you unload the modules, it will have to be the last one unloaded.
+
+	The individual upper and lower level drivers can be loaded in any
+order once the scsi core is present in the kernel (either compiled in
+or loaded as a module).  The disk driver (sd_mod.o), cdrom driver (sr_mod.o),
+tape driver (st.o) and scsi generics driver (sg.o) represent the upper level
+drivers to support the various assorted devices which can be controlled.
+You can for example load the tape driver to use the tape drive, and then
+unload it once you have no further need for the driver (and release the
+associated memory).
+
+	The lower level drivers are the ones that support the
+individual cards that are supported for the hardware platform that you
+are running under.  Examples are aha1542.o to drive Adaptec 1542
+cards.  Rather than list the drivers which *can* be modularized, it is
+easier to list the ones which cannot, since the list only contains a
+few entries.  The drivers which have NOT been modularized are:
+
+	NCR5380 boards of one kind or another including PAS16,
+		Trantor T128/128F/228, 
+
diff --git a/Documentation/smp.tex b/Documentation/smp.tex
new file mode 100644
index 000000000..ea582088c
--- /dev/null
+++ b/Documentation/smp.tex
@@ -0,0 +1,346 @@
+From: michael@Physik.Uni-Dortmund.DE (Michael Dirkmann)
+
+thanks for your information. Attached is the tex-code of your
+SMP-documentation :
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+\documentclass[]{article}
+\parindent0.0cm
+\parskip0.2cm
+
+\begin{document}
+
+\begin{center}
+\LARGE \bf
+An Implementation Of Multiprocessor Linux
+\normalsize
+\end{center}
+
+{ \it
+This document describes the implementation of a simple SMP 
+Linux kernel extension and how to use this to develop SMP Linux kernels for 
+architectures other than the Intel MP v1.1 architecture for Pentium and 486 
+processors.}
+
+\hfill Alan Cox, 1995
+
+
+The author wishes to thank Caldera Inc ( http://www.caldera.com )
+whose donation of an ASUS dual pentium board made this project possible, 
+and Thomas Radke, whose initial work on multiprocessor Linux formed 
+the backbone of this project.
+
+\section{Background: The Intel MP specification.}
+Most IBM PC style multiprocessor motherboards combine Intel 486 or Pentium 
+processors and glue chipsets with a hardware/software specification. The 
+specification places much of the onus for hard work on the chipset and 
+hardware rather than the operating system.
+
+The Intel pentium processors have a wide variety of inbuilt facilities for 
+supporting multiprocessing, including hardware cache coherency, built in 
+interprocessor interrupt handling and a set of atomic test and set, 
+exchange and similar operations. The cache coherency in particular makes the 
+operating systems job far easier.
+
+The specification defines a detailed configuration structure in ROM that 
+the boot up processor can read to find the full configuration of the 
+processors and busses. It also defines a procedure for starting up the 
+other processors.
+
+
+\section{Mutual Exclusion Within A Single Processor Linux Kernel}
+For any kernel to function in a sane manner it has to provide internal 
+locking and protection of its own tables to prevent two processes updating 
+them at once and for example allocating the same memory block. There are 
+two strategies for this within current Unix and Unixlike kernels. 
+Traditional unix systems from the earliest of days use a scheme of 'Coarse 
+Grained Locking' where the entire kernel is protected as a small number of 
+locks only. Some modern systems use fine grained locking. Because fine 
+grained locking has more overhead it is normally used only on 
+multiprocessor kernels and real time kernels. In a real time kernel the 
+fine grained locking reduces the amount of time locks are held and reduces 
+the critical (to real time programming at least) latency times.
+
+Within the Linux kernel certain guarantees are made. No process running in 
+kernel mode will be pre-empted by another kernel mode process unless it 
+voluntarily sleeps.  This ensures that blocks of kernel code are 
+effectively atomic with respect to other processes and greatly simplifies 
+many operation. Secondly interrupts may pre-empt a kernel running process, 
+but will always return to that process. A process in kernel mode may 
+disable interrupts on the processor and guarantee such an interruption will 
+not occur. The final guarantee is that an interrupt will not be pre-empted 
+by a kernel task. That is interrupts will run to completion or be 
+pre-empted by other interrupts only.
+
+The SMP kernel chooses to continue these basic guarantees in order to make 
+initial implementation and deployment easier.  A single lock is maintained 
+across all processors. This lock is required to access the kernel space. 
+Any processor may hold it and once it is held may also re-enter the kernel 
+for interrupts and other services whenever it likes until the lock is 
+relinquished. This lock ensures that a kernel mode process will not be 
+pre-empted and ensures that blocking interrupts in kernel mode behaves 
+correctly. This is guaranteed because only the processor holding the lock 
+can be in kernel mode, only kernel mode processes can disable interrupts 
+and only the processor holding the lock may handle an interrupt.
+
+Such a choice is however poor for performance. In the longer term it is 
+necessary to move to finer grained parallelism in order to get the best 
+system performance. This can be done hierarchically by gradually refining 
+the locks to cover smaller areas. With the current kernel highly CPU bound 
+process sets perform well but I/O bound task sets can easily degenerate to 
+near single processor performance levels. This refinement will be needed to 
+get the best from Linux/SMP.
+
+\subsection{Changes To The Portable Kernel Components}
+The kernel changes are split into generic SMP support changes and 
+architecture specific changes necessary to accommodate each different 
+processor type Linux is ported to.
+
+
+\subsubsection{Initialisation}
+The first problem with a multiprocessor kernel is starting the other 
+processors up. Linux/SMP defines that a single processor enters the normal 
+kernel entry point start\_kernel(). Other processors are assumed not to be 
+started or to have been captured elsewhere. The first processor begins the 
+normal Linux initialisation sequences and sets up paging, interrupts and 
+trap handlers. After it has obtained the processor information about the 
+boot CPU, the architecture specific function 
+
+
+{\tt \bf{void smp\_store\_cpu\_info(int processor\_id) }}
+
+is called to store any information about the processor into a per processor 
+array. This includes things like the bogomips speed ratings.
+
+Having completed the kernel initialisation the architecture specific 
+function
+
+{\tt \bf void smp\_boot\_cpus(void) }
+
+is called and is expected to start up each other processor and cause it to 
+enter start\_kernel() with its paging registers and other control 
+information correctly loaded. Each other processor skips the setup except 
+for calling the trap and irq initialisation functions that are needed on 
+some processors to set each CPU up correctly.  These functions will 
+probably need to be modified in existing kernels to cope with this.
+
+
+Each additional CPU the calls the architecture specific function
+
+{\tt \bf void smp\_callin(void)}
+
+which does any final setup and then spins the processor while the boot 
+up processor forks off enough idle threads for each processor. This is 
+necessary because the scheduler assumes there is always something to run. 
+Having generated these threads and forked init the architecture specific 
+
+{\tt \bf void smp\_commence(void)}
+
+function is invoked. This does any final setup and indicates to the system 
+that multiprocessor mode is now active. All the processors spinning in the 
+smp\_callin() function are now released to run the idle processes, which 
+they will run when they have no real work to process.
+
+
+\subsubsection{Scheduling}
+The kernel scheduler implements a simple but very and effective task 
+scheduler. The basic structure of this scheduler is unchanged in the 
+multiprocessor kernel. A processor field is added to each task, and this 
+maintains the number of the processor executing a given task, or a magic 
+constant (NO\_PROC\_ID)  indicating the job is not allocated to a processor. 
+	 
+Each processor executes the scheduler itself and will select the next task 
+to run from all runnable processes not allocated to a different processor. 
+The algorithm used by the selection is otherwise unchanged. This is 
+actually inadequate for the final system because there are advantages to 
+keeping a process on the same CPU, especially on processor boards with per 
+processor second level caches.
+
+Throughout the kernel the variable 'current' is used as a global for the 
+current process. In Linux/SMP this becomes a macro which expands to 
+current\_set[smp\_processor\_id()]. This enables almost the entire kernel to 
+be unaware of the array of running processors, but still allows the SMP 
+aware kernel modules to see all of the running processes.
+
+The fork system call is modified to generate multiple processes with a 
+process id of zero until the SMP kernel starts up properly. This is 
+necessary because process number 1 must be init, and it is desirable that 
+all the system threads are process 0. 
+
+The final area within the scheduling of processes that does cause problems 
+is the fact the uniprocessor kernel hard codes tests for the idle threads 
+as task[0] and the init process as task[1]. Because there are multiple idle 
+threads it is necessary to replace these with tests that the process id is 
+0 and a search for process ID 1, respectively.
+
+\subsubsection{Memory Management}
+The memory management core of the existing Linux system functions 
+adequately within the multiprocessor framework providing the locking is 
+used. Certain processor specific areas do need changing, in particular 
+invalidate() must invalidate the TLB's of all processors before it returns.
+
+
+\subsubsection{Miscellaneous Functions}
+The portable SMP code rests on a small set of functions and variables 
+that are provided by the processor specification functionality. These are
+
+{\tt \bf int smp\_processor\_id(void) }
+
+which returns the identity of the process the call is executed upon. This 
+call is assumed to be valid at all times. This may mean additional tests 
+are needed during initialisation.
+
+
+{\tt \bf int smp\_num\_cpus;}
+
+This is the number of processors in the system. \
+
+{\tt \bf void smp\_message\_pass(int target, int msg, unsigned long data,
+		int wait)}
+
+This function passes messages between processors. At the moment it is not 
+sufficiently defined to sensibly document and needs cleaning up and further 
+work. Refer to the processor specific code documentation for more details.
+
+
+\subsection{Architecture Specific Code For the Intel MP Port}
+The architecture specific code for the intel port splits fairly cleanly 
+into four sections. Firstly the initialisation code used to boot the 
+system, secondly the message handling and support code, thirdly the 
+interrupt and kernel syscall entry function handling and finally the 
+extensions to standard kernel facilities to cope with multiple processors.
+
+\subsubsection{Initialisation}	
+The intel MP architecture captures all the processors except for a single 
+processor known as the 'boot processor' in the BIOS at boot time. Thus a 
+single processor enters the kernel bootup code. The first processor 
+executes the bootstrap code, loads and uncompresses the kernel. Having 
+unpacked the kernel it sets up the paging and control registers then enters 
+the C kernel startup.
+
+The assembler startup code for the kernel is modified so that it can be 
+used by the other processors to do the processor identification and various 
+other low level configurations but does not execute those parts of the 
+startup code that would damage the running system (such as clearing the BSS 
+segment). 
+
+In the initialisation done by the first processor the arch/i386/mm/init 
+code is modified to scan the low page, top page and BIOS for intel MP 
+signature blocks. This is necessary because the MP signature blocks must 
+be read and processed before the kernel is allowed to allocate and destroy 
+the page at the top of low memory. Having established the number of 
+processors it reserves a set of pages to provide a stack come boot up area 
+for each processor in the system. These must be allocated at startup to 
+ensure they fall below the 1Mb boundary.
+
+Further processors are started up in smp\_boot\_cpus() by programming the 
+APIC controller registers and sending an inter-processor interrupt (IPI) to 
+the processor. This message causes the target processor to begin executing 
+code at the start of any page of memory within the lowest 1Mb, in 16bit 
+real mode. The kernel uses the single page it allocated for each processor 
+to use as stack. Before booting a given CPU the relocatable code from 
+trampoline.S and trampoline32.S is copied to the bottom of its stack page 
+and used as the target for the startup. 
+
+The trampoline code calculates the desired stack base from the code 
+segment (since the code segment on startup is the bottom of the stack), 
+ enters 32bit mode and jumps to the kernel entry assembler. This as 
+described above is modified to only execute the parts necessary for each 
+processor, and then to enter start\_kernel(). On entering the kernel the 
+processor initialises its trap and interrupt handlers before entering 
+smp\_callin(), where it reports its status and sets a flag that causes the 
+boot processor to continue and look for further processors. The processor 
+then spins until smp\_commence() is invoked.
+
+Having started each processor up the smp\_commence( ) function flips a 
+flag. Each processor spinning in smp\_callin() then loads the task register 
+with the task state segment (TSS) of its idle thread as is needed for task 
+switching.
+
+\subsubsection{Message Handling and Support Code}
+The architecture specific code implements the smp\_processor\_id() function 
+by querying the APIC logical identity register. Because the APIC isn't 
+mapped into the kernel address space at boot, the initial value returned is 
+rigged by setting the APIC base pointer to point at a suitable constant. 
+Once the system starts doing the SMP setup (in smp\_boot\_cpus()), the APIC 
+is mapped with a vremap() call and the apic pointer is adjusted 
+appropriately. From then on the real APIC logical identity register is 
+read.
+
+Message passing is accomplished using a pair of IPI's on interrupt 13 
+(unused by the 80486 FPU's in SMP mode) and interrupt 16. Two are used in 
+order to separate messages that cannot be processed until the receiver 
+obtains the kernel spinlock from messages that can be processed 
+immediately. In effect IRQ 13 is a fast IRQ handler that does not obtain 
+the locks, and cannot cause a reschedule, while IRQ 16 is a slow IRQ that 
+must acquire the kernel spinlocks and can cause a reschedule. This 
+interrupt is used for passing on slave timer messages from the processor 
+that receives the timer interrupt to the rest of the processors, so that 
+they can reschedule running tasks.
+
+
+\subsubsection{Entry And Exit Code}
+A single spinlock protects the entire kernel. The interrupt handlers, the 
+syscall entry code and the exception handlers all acquire the lock before 
+entering the kernel proper. When the processor is trying to acquire the 
+spinlock it spins continually on the lock with interrupts disabled. This 
+causes a specific deadlock problem. The lock owner may need to send an 
+invalidate request to the rest of the processors and wait for these to 
+complete before continuing. A processor spinning on the lock would not be 
+able to do thus. Thus the loop of the spinlock tests and handles invalidate 
+requests. If the invalidate bit for the spinning CPU is set the processor 
+invalidates its TLB and atomically clears the bit. When the spinlock is 
+obtained that processor will take an IPI and in the IPI test the bit and 
+skip the invalidate as the bit is clear.
+
+One complexity of the spinlock is that a process running in kernel mode 
+can sleep voluntarily and be pre-empted. A switch from such a process to a 
+process executing in user space may reduce the lock count. To track this 
+the kernel uses a syscall\_count and a per process lock\_depth parameter to 
+track the kernel lock state. The switch\_to() function is modified in SMP 
+mode to adjust the lock appropriately.
+
+The final problem is the idle thread. In the single processor kernel the 
+idle thread executes 'hlt' instructions. This saves power and reduces the 
+running temperature of the processors when they are idle. However it means 
+the process spends all its time in kernel mode and would thus hold the 
+kernel spinlock. The SMP idle thread continually reschedules a new task and 
+returns to user mode. This is far from ideal and will be modified to use 
+'hlt' instructions and release the spinlock soon. Using 'hlt' is even more 
+beneficial on a multiprocessor system as it almost completely takes an idle 
+processor off the bus.
+
+Interrupts are distributed by an i82489 APIC. This chip is set up to work 
+as an emulation of the traditional PC interrupt controllers when the 
+machine boots (so that an Intel MP machine boots one CPU and PC 
+compatible). The kernel has all the relevant locks but does not yet 
+reprogram the 82489 to deliver interrupts to arbitrary processors as it 
+should. This requires further modification of the standard Linux interrupt 
+handling code, and is particularly messy as the interrupt handler behaviour 
+has to change as soon as the 82489 is switched into SMP mode.
+
+
+\subsubsection{Extensions To Standard Facilities}
+The kernel maintains a set of per processor control information such as 
+the speed of the processor for delay loops. These functions on the SMP 
+kernel look the values up in a per processor array that is set up from the 
+data generated at boot up by the smp\_store\_cpu\_info() function. This 
+includes other facts such as whether there is an FPU on the processor. The 
+current kernel does not handle floating point correctly, this requires some 
+changes to the techniques the single CPU kernel uses to minimise floating 
+point processor reloads.
+
+The highly useful atomic bit operations are prefixed with the 'lock' 
+prefix in the SMP kernel to maintain their atomic properties when used 
+outside of (and by) the spinlock and message code. Amongst other things 
+this is needed for the invalidate handler, as all  CPU's will invalidate at 
+the same time without any locks.
+
+Interrupt 13 floating point error reporting is removed. This facility is 
+not usable on a multiprocessor board, nor relevant to the Intel MP 
+architecture which does not cover the 80386/80387 processor pair. \
+
+The /proc filesystem support is changed so that the /proc/cpuinfo file 
+contains a column for each processor present. This information is extracted 
+from the data save by smp\_store\_cpu\_info().
+
+\end{document}
diff --git a/Documentation/svga.txt b/Documentation/svga.txt
new file mode 100644
index 000000000..049f952ef
--- /dev/null
+++ b/Documentation/svga.txt
@@ -0,0 +1,268 @@
+		       Video Mode Selection Support 2.10
+	      (c) 1995, 1996 Martin Mares, <mj@k332.feld.cvut.cz>
+--------------------------------------------------------------------------------
+
+1. Intro
+~~~~~~~~
+   This small document describes the "Video Mode Selection" feature which
+allows to use various special video modes supported by the video BIOS. Due
+to usage of the BIOS, the selection is limited to the boot time (before the
+kernel decompression starts and works only on 80X86 machines.
+
+   IF YOU USE THIS FEATURE, I'LL BE MUCH PLEASED IF YOU SEND ME A MAIL
+DESCRIBING YOUR EXPERIENCE WITH IT. BUG REPORTS ARE ALSO WELCOME.
+
+   The video mode to be used is selected by a kernel parameter which can be
+specified in the kernel Makefile (the SVGA_MODE=... line) or by the "vga=..."
+option of LILO or by the "vidmode" utility (present in standard Linux utility
+packages). You can use the following settings of this parameter:
+
+   NORMAL_VGA - Standard 80x25 mode available on all display adapters.
+
+   EXTENDED_VGA	- Standard 8-pixel font mode: 80x43 on EGA, 80x50 on VGA.
+
+   ASK_VGA - Display a video mode menu upon startup (see below).
+
+   0..35 - Menu item number (when you have used the menu to view the list of
+      modes available on your adapter, you can specify the menu item you want
+      to use). 0..9 correspond to "0".."9", 10..35 to "a".."z". Warning: the
+      mode list displayed may vary as the kernel version changes, because the
+      modes are listed in a "first detected -- first displayed" manner. It's
+      better to use absolute mode numbers instead.
+
+   0x.... - Hexadecimal video mode ID (also displayed on the menu, see below
+      for exact meaning of the ID). Warning: rdev and LILO don't support
+      hexadecimal numbers -- you have to convert it to decimal manually.
+
+2. Menu
+~~~~~~~
+   The ASK_VGA mode causes the kernel to offer a video mode menu upon
+bootup. It displays a "Press <RETURN> to see video modes available, <SPACE>
+to continue or wait 30 secs" message. If you press <RETURN>, you enter the
+menu, if you press <SPACE> or wait 30 seconds, the kernel will boot up with
+the standard 80x25 mode set.
+
+   The menu looks like:
+
+Video adapter: <name-of-detected-video-adapter>
+Mode:    COLSxROWS:
+0  0F00  80x25
+1  0F01  80x50
+2  0F02  80x43
+3  0F03  80x26
+....
+Enter mode number: <flashing-cursor-here>
+
+   <name-of-detected-video-adapter> should contain a name of your video adapter
+or the chip in it or at least whether it's an EGA or VGA or VESA VGA (VGA with
+a VESA-compliant BIOS in it). If it doesn't match your configuration, tell me
+and I'll try to fix it somehow (you know, hardware detection is a real pain
+on PC's).
+
+   "0  0F00  80x25" tells that the first menu item (the menu items are numbered
+from "0" to "9" and from "a" to "z") is a 80x25 mode with ID=0x0f00 (see the
+next section for a description of the mode ID's).
+
+   <flashing-cursor-here> encourages you to write the item number or mode ID
+you wish to set and press <RETURN>. If the computer complains something about
+"Unknown mode ID", it tries to explain you that it isn't possible to set such
+a mode. It's also possible to press only <RETURN> which forces the current
+mode to be used.
+
+   The mode list may be a bit inaccurate on your machine (it isn't possible
+to autodetect all existing video cards and their mutations). Some of the
+modes may be unsettable, some of them might work incorrectly with Linux
+(the common case is mirroring of first few lines at the bottom of the screen
+because of BIOS bugs) or there can exist modes which are not displayed. If
+you think the list doesn't match your configuration, let me know and I'll try
+to add your configuration to the next version of the mode selector.
+
+   The modes displayed on the menu are partially sorted: The list starts with
+the standard modes (80x25 and 80x50) followed by "special" modes (80x28 and
+80x43), local modes (if the local modes feature is enabled), VESA modes and
+finally SVGA modes for the auto-detected adapter.
+
+   If you enter "scan" instead of item number / mode ID, the program will try
+to scan your video modes in a slightly aggressive, but much more accurate way.
+This should reveal all video modes supported by your BIOS. During this process,
+the screen will flash wildly and strange things will appear. If you are afraid
+this could damage your monitor, don't use this functions. After scanning, the
+mode ordering is a bit different: the auto-detected SVGA modes are not listed
+at all and the modes revealed by the scan are shown before the VESA modes.
+
+3. Mode ID's
+~~~~~~~~~~~~
+   Because of the complexity of all the video stuff, the video mode ID's
+used here are also a bit complex. A video mode ID is a 16-bit number usually
+expressed in a hexadecimal notation (starting with "0x"). The ID numbers
+can be divided to three regions:
+
+   0x0000 to 0x00ff - menu item references. 0x0000 is the first item.
+
+   0x0100 to 0x017f - standard BIOS modes. The ID is a BIOS video mode number
+	(as presented to INT 10, function 00) increased by 0x0100. You can
+	use any mode numbers even if not shown on the menu.
+
+   0x0200 to 0x08ff - VESA BIOS modes. The ID is a VESA mode ID increased by
+	0x0100. All VESA modes should be autodetected and shown on the menu.
+
+   0x0900 to 0x09ff - Video7 special modes. Set by calling INT 0x10, AX=0x6f05.
+
+   0x0f00 to 0x0fff - special modes (they are set by various tricks -- usually
+	by modifying one of the standard modes). Currently available:
+	0x0f00	standard 80x25, don't reset mode if already set (=FFFF)
+	0x0f01	standard with 8-point font: 80x43 on EGA, 80x50 on VGA
+	0x0f02	VGA 80x43 (VGA switched to 350 scanlines with a 8-point font)
+	0x0f03	VGA 80x28 (standard VGA scans, but 14-point font)
+	0x0f04	leave current video mode
+	0x0f05	VGA 80x30 (480 scans, 16-point font)
+	0x0f06	VGA 80x34 (480 scans, 14-point font)
+	0x0f07	VGA 80x60 (480 scans, 8-point font)
+	0x0f08	Graphics hack (see the CONFIG_VIDEO_HACK paragraph below)
+
+   0x1000 to 0x7fff - modes specified by resolution. The code has a "0xRRCC"
+	form where RR is a number of rows and CC is a number of columns.
+	E.g., 0x1950 corresponds to a 80x25 mode, 0x2b84 to 132x43 etc.
+	This is the only fully portable way to refer to a non-standard mode.
+
+   0xff00 to 0xffff - aliases for backward compatibility:
+	0xffff	equivalent to 0x0f00 (standard 80x25)
+	0xfffe	equivalent to 0x0f01 (EGA 80x43 or VGA 80x50)
+
+   If you add 0x8000 to the mode ID, the program will try to recalculate
+vertical display timing according to mode parameters, which can be used to
+eliminate some annoying bugs of certain VGA BIOS'es -- mainly extra lines at
+the end of the display.
+
+4. Options
+~~~~~~~~~~
+   Some options can be set in the source text (in arch/i386/boot/video.S).
+All of them are simple #define's -- change them to #undef's when you want to
+switch them off. Currently supported:
+
+   CONFIG_VIDEO_SVGA - enables autodetection of SVGA cards. If your card is
+detected incorrectly, you can switch this off.
+
+   CONFIG_VIDEO_VESA - enables autodetection of VESA modes. If it doesn't work
+on your machine (or displays a "Error: Scanning of VESA modes failed" message),
+you can switch it off and report as a bug.
+
+   CONFIG_VIDEO_COMPACT - enables compacting of the video mode list. Duplicate
+entries (those with the same screen size) are deleted except for the first one
+(see the previous section for more information on mode ordering). However,
+it's possible that the first variant doesn't work, while some of the others do
+-- in this case turn this switch off to see the rest.
+
+   CONFIG_VIDEO_RETAIN - enables retaining of screen contents when switching
+video modes. Works only with some boot loaders which leave enough room for the
+buffer.
+
+   CONFIG_VIDEO_LOCAL - enables inclusion of "local modes" in the list. The
+local modes are added automatically to the beginning of the list not depending
+by hardware configuration. The local modes are listed in the source text after
+the "local_mode_table:" line. The comment before this line describes the format
+of the table (which also includes a video card name to be displayed on the
+top of the menu).
+
+   CONFIG_VIDEO_400_HACK - force setting of 400 scan lines for standard VGA
+modes. This option is intended to be used on certain buggy BIOS'es which draw
+some useless logo using font download and then fail to reset the correct mode.
+Don't use unless needed as it forces resetting the video card.
+
+   CONFIG_VIDEO_GFX_HACK - includes special hack for setting of graphics modes
+to be used later by special drivers (e.g., 800x600 on IBM ThinkPad -- see
+ftp://ftp.phys.keio.ac.jp/pub/XFree86/800x600/XF86Configs/XF86Config.IBM_TP560).
+Allows to set _any_ BIOS mode including graphic ones and forcing specific
+text screen resolution instead of peeking it from BIOS variables. Don't use
+unless you think you know what you're doing. To activate this setup, use
+mode number 0x0f08 (see section 3).
+
+5. Adding more cards
+~~~~~~~~~~~~~~~~~~~~
+   If you have a card not detected by the driver and you are a good programmer,
+feel free to add it to the source and send me a diff. It's very simple: You
+have to add a new entry to the svga_table consisting of a pointer to your mode
+table and a pointer to your detection routine. The order of entries in the
+svga_table defines the order of probing. Please use only reliable detection
+routines which are known to identify _only_ the card in question.
+
+   The detection routine is called with BP pointing to your mode table and
+ES containing 0xc000. If you want, you may alter BP allowing to select an
+appropriate mode table according to model ID detected. If the detection fails,
+return BP=0.
+
+   The mode table consists of lines containing a (BIOS mode number, rows,
+columns) triple and is finished by single zero byte followed by NUL-terminated
+adapter name.
+
+6. Still doesn't work?
+~~~~~~~~~~~~~~~~~~~~~~
+   When the mode detection doesn't work (e.g., the mode list is incorrect or
+the machine hangs instead of displaying the menu), try to switch off some of
+the configuration options listed in section 4. If it fails, you can still use
+your kernel with the video mode set directly via the kernel parameter.
+
+   In either case, please send me a bug report containing what _exactly_
+happens and how do the configuration switches affect the behaviour of the bug.
+
+   If you start Linux from the M$-DOS, you might also use some DOS tools for
+video mode setting. In this case, you must specify the 0x0f04 mode ("leave
+current settings") to Linux, because if you use anything other, the 80x25
+mode will be used automatically.
+
+   If you set some SVGA mode and there's one or more extra lines on the
+bottom of the display containing already scrolled-out lines, your VGA BIOS
+contains the most common video BIOS bug called "incorrect vertical display
+end setting". Adding 0x8000 to the mode ID might fix the problem. Unfortunately,
+this must be done manually -- no autodetection mechanisms are available.
+
+   If you have a VGA card and your display still looks as on EGA, your BIOS
+is probably broken and you need to set the CONFIG_VIDEO_400_HACK switch to
+force setting of the correct mode.
+
+7. History
+~~~~~~~~~~
+1.0 (??-Nov-95)	First version supporting all adapters supported by the old
+		setup.S + Cirrus Logic 54XX. Present in some 1.3.4? kernels
+		and then removed due to instability on some machines.
+2.0 (28-Jan-96)	Rewritten from scratch. Cirrus Logic 64XX support added, almost
+		everything is configurable, the VESA support should be much more
+		stable, explicit mode numbering allowed, "scan" implemented etc.
+2.1 (30-Jan-96) VESA modes moved to 0x200-0x3ff. Mode selection by resolution
+		supported. Few bugs fixed. VESA modes are listed prior to
+		modes supplied by SVGA autodetection as they are more reliable.
+		CLGD autodetect works better. Doesn't depend on 80x25 being
+		active when started. Scanning fixed. 80x43 (any VGA) added.
+		Code cleaned up.
+2.2 (01-Feb-96)	EGA 80x43 fixed. VESA extended to 0x200-0x4ff (non-standard 02XX
+		VESA modes work now). Display end bug workaround supported.
+		Special modes renumbered to allow adding of the "recalculate"
+		flag, 0xffff and 0xfffe became aliases instead of real ID's.
+		Screen contents retained during mode changes.
+2.3 (15-Mar-96)	Changed to work with 1.3.74 kernel.
+2.4 (18-Mar-96)	Added patches by Hans Lermen fixing a memory overwrite problem
+		with some boot loaders. Memory management rewritten to reflect
+		these changes. Unfortunately, screen contents retaining works
+		only with some loaders now.
+		Added a Tseng 132x60 mode.
+2.5 (19-Mar-96)	Fixed a VESA mode scanning bug introduced in 2.4.
+2.6 (25-Mar-96)	Some VESA BIOS errors not reported -- it fixes error reports on
+		several cards with broken VESA code (e.g., ATI VGA).
+2.7 (09-Apr-96)	- Accepted all VESA modes in range 0x100 to 0x7ff, because some
+		  cards use very strange mode numbers.
+		- Added Realtek VGA modes (thanks to Gonzalo Tornaria).
+		- Hardware testing order slightly changed, tests based on ROM
+		  contents done as first.
+		- Added support for special Video7 mode switching functions
+		  (thanks to Tom Vander Aa).
+		- Added 480-scanline modes (especially useful for notebooks,
+		  original version written by hhanemaa@cs.ruu.nl, patched by
+		  Jeff Chua, rewritten by me).
+		- Screen store/restore fixed.
+2.8 (14-Apr-96)	- Previous release was not compilable without CONFIG_VIDEO_SVGA.
+		- Better recognition of text modes during mode scan.
+2.9 (12-May-96)	- Ignored VESA modes 0x80 - 0xff (more VESA BIOS bugs!)
+2.10 (11-Nov-96)- The whole thing made optional.
+		- Added the CONFIG_VIDEO_400_HACK switch.
+		- Added the CONFIG_VIDEO_GFX_HACK switch.
+		- Code cleanup.
diff --git a/Documentation/unicode.txt b/Documentation/unicode.txt
new file mode 100644
index 000000000..b9f44a6eb
--- /dev/null
+++ b/Documentation/unicode.txt
@@ -0,0 +1,139 @@
+The Linux kernel code has been rewritten to use Unicode to map
+characters to fonts.  By downloading a single Unicode-to-font table,
+both the eight-bit character sets and UTF-8 mode are changed to use
+the font as indicated.
+
+This changes the semantics of the eight-bit character tables subtly.
+The four character tables are now:
+
+Map symbol	Map name			Escape code (G0)
+
+LAT1_MAP	Latin-1 (ISO 8859-1)		ESC ( B
+GRAF_MAP	DEC VT100 pseudographics	ESC ( 0
+IBMPC_MAP	IBM code page 437		ESC ( U
+USER_MAP	User defined			ESC ( K
+
+In particular, ESC ( U is no longer "straight to font", since the font
+might be completely different than the IBM character set.  This
+permits for example the use of block graphics even with a Latin-1 font
+loaded.
+
+In accordance with the Unicode standard/ISO 10646 the range U+F000 to
+U+F8FF has been reserved for OS-wide allocation (the Unicode Standard
+refers to this as a "Corporate Zone", since this is inaccurate for
+Linux we call it the "Linux Zone").  U+F000 was picked as the starting
+point since it lets the direct-mapping area start on a large power of
+two (in case 1024- or 2048-character fonts ever become necessary).
+This leaves U+E000 to U+EFFF as End User Zone.
+
+The Unicodes in the range U+F000 to U+F1FF have been hard-coded to map
+directly to the loaded font, bypassing the translation table.  The
+user-defined map now defaults to U+F000 to U+F1FF, emulating the
+previous behaviour.  This range may expand in the future should it be
+warranted.
+
+Actual characters assigned in the Linux Zone
+--------------------------------------------
+
+In addition, the following characters not present in Unicode 1.1.4 (at
+least, I have not found them!) have been defined; these are used by
+the DEC VT graphics map:
+
+U+F800 DEC VT GRAPHICS HORIZONTAL LINE SCAN 1
+U+F801 DEC VT GRAPHICS HORIZONTAL LINE SCAN 3
+U+F803 DEC VT GRAPHICS HORIZONTAL LINE SCAN 7
+U+F804 DEC VT GRAPHICS HORIZONTAL LINE SCAN 9
+
+The DEC VT220 uses a 6x10 character matrix, and these characters form
+a smooth progression in the DEC VT graphics character set.  I have
+omitted the scan 5 line, since it is also used as a block-graphics
+character, and hence has been coded as U+2500 FORMS LIGHT HORIZONTAL.
+However, I left U+F802 blank should the need arise.  
+
+Klingon language support
+------------------------
+
+Unfortunately, Unicode/ISO 10646 does not allocate code points for the
+language Klingon, probably fearing the potential code point explosion
+if many fictional languages were submitted for inclusion.  There are
+also political reasons (the Japanese, for example, are not too happy
+about the whole 16-bit concept to begin with.)  However, with Linux
+being a hacker-driven OS it seems this is a brilliant linguistic hack
+worth supporting.  Hence I have chosen to add it to the list in the
+Linux Zone.
+
+Several glyph forms for the Klingon alphabet has been proposed.
+However, since the set of symbols appear to be consistent throughout,
+with only the actual shapes being different, in keeping with standard
+Unicode practice these differences are considered font variants.
+
+Klingon has an alphabet of 26 characters, a positional numeric writing
+system with 10 digits, and is written left-to-right, top-to-bottom.
+Punctuation appears to be only used in Latin transliteration; it is
+appears customary to write each sentence on its own line, and
+centered.  Space has been reserved for punctuation should it prove
+necessary.
+
+This encoding has been endorsed by the Klingon Language Institute.
+For more information, contact them at:
+
+	http://www.kli.org/
+
+Since the characters in the beginning of the Linux CZ have been more
+of the dingbats/symbols/forms type and this is a language, I have
+located it at the end, on a 16-cell boundary in keeping with standard
+Unicode practice.
+
+U+F8D0	KLINGON LETTER A
+U+F8D1	KLINGON LETTER B
+U+F8D2	KLINGON LETTER CH
+U+F8D3	KLINGON LETTER D
+U+F8D4	KLINGON LETTER E
+U+F8D5	KLINGON LETTER GH
+U+F8D6	KLINGON LETTER H
+U+F8D7	KLINGON LETTER I
+U+F8D8	KLINGON LETTER J
+U+F8D9	KLINGON LETTER L
+U+F8DA	KLINGON LETTER M
+U+F8DB	KLINGON LETTER N
+U+F8DC	KLINGON LETTER NG
+U+F8DD	KLINGON LETTER O
+U+F8DE	KLINGON LETTER P
+U+F8DF	KLINGON LETTER Q
+	- Written <q> in standard Okrand Latin transliteration
+U+F8E0	KLINGON LETTER QH
+	- Written <Q> in standard Okrand Latin transliteration
+U+F8E1	KLINGON LETTER R
+U+F8E2	KLINGON LETTER S
+U+F8E3	KLINGON LETTER T
+U+F8E4	KLINGON LETTER TLH
+U+F8E5	KLINGON LETTER U
+U+F8E6	KLINGON LETTER V
+U+F8E7	KLINGON LETTER W
+U+F8E8	KLINGON LETTER Y
+U+F8E9	KLINGON LETTER GLOTTAL STOP
+
+U+F8F0	KLINGON DIGIT ZERO
+U+F8F1	KLINGON DIGIT ONE
+U+F8F2	KLINGON DIGIT TWO
+U+F8F3	KLINGON DIGIT THREE
+U+F8F4	KLINGON DIGIT FOUR
+U+F8F5	KLINGON DIGIT FIVE
+U+F8F6	KLINGON DIGIT SIX
+U+F8F7	KLINGON DIGIT SEVEN
+U+F8F8	KLINGON DIGIT EIGHT
+U+F8F9	KLINGON DIGIT NINE
+
+Other Fictional and Artificial Scripts
+--------------------------------------
+
+Since the assignment of the Klingon Linux Unicode block, a registry of
+fictional and artificial scripts has been established by John Cowan,
+<cowan@ccil.org>.  The ConScript Unicode Registry is accessible at
+http://locke.ccil.org/~cowan/csur/; the ranges used fall at the bottom
+of the End User Zone and can hence not be normatively assigned, but it
+is recommended that people who wish to encode fictional scripts use
+these codes, in the interest of interoperability.  For Klingon, CSUR
+has adopted the Linux encoding.
+
+	H. Peter Anvin <hpa@zytor.com>
diff --git a/Documentation/watchdog.txt b/Documentation/watchdog.txt
new file mode 100644
index 000000000..940313a94
--- /dev/null
+++ b/Documentation/watchdog.txt
@@ -0,0 +1,83 @@
+	Watchdog Timer Interfaces For The Linux Operating System
+
+		Alan Cox <alan@lxorguk.ukuu.org.uk>
+
+	     Custom Linux Driver And Program Development
+
+
+The following watchdog drivers are currently implemented:
+
+	ICS	WDT501-P
+	ICS	WDT501-P (no fan tachometer)
+	ICS	WDT500-P
+	Software Only
+
+All four interfaces provide /dev/watchdog, which when open must be written
+to within a minute or the machine will reboot. Each write delays the reboot
+time another minute. In the case of the software watchdog the ability to 
+reboot will depend on the state of the machines and interrupts. The hardware
+boards physically pull the machine down off their own onboard timers and
+will reboot from almost anything.
+
+A second temperature monitoring interface is available on the WDT501P cards
+and provides /dev/temperature. This is the machine internal temperature in
+degrees farenheit. Each read returns a single byte giving the temperature.
+
+The third interface logs kernel messages on additional alert events.
+
+Both software and hardware watchdog drivers are available in the standard
+kernel. If you are using the software watchdog, you probably also want
+to use "panic=60" as a boot argument as well.
+
+Features
+--------
+		WDT501P		WDT500P		Software
+Reboot Timer	   X               X                X
+External Reboot	   X	           X                o
+Temperature	   X		   o		    o
+Fan Speed          X		   o		    o
+Power Under	   X               o                o
+Power Over         X               o                o
+Overheat           X               o                o
+
+The external event interfaces on the WDT boards are not currently supported.
+Minor numbers are however allocated for it.
+
+
+Example Watchdog Driver
+-----------------------
+
+#include <stdio.h>
+#include <unistd.h>
+#include <fcntl.h>
+
+int main(int argc, const char *argv[])
+{
+	int fd=open("/dev/watchdog",O_WRONLY);
+	if(fd==-1)
+	{
+		perror("watchdog");
+		exit(1);
+	}
+	while(1)
+	{
+		write(fd,"\0",1);
+		sleep(10);
+	}
+}
+
+
+Contact Information
+
+People keep asking about the WDT watchdog timer hardware: The phone contacts
+for Industrial Computer Source are:
+ 
+US: 619 677 0877 (sales)  0895 (fax)
+UK: 01243 533900
+France (1) 69.18.74.30
+
+Industrial Computer Source 
+9950 Barnes Canyon Road 
+San Diego, CA     
+
+and please mention Linux when enquiring.
diff --git a/Documentation/xterm-linux.xpm b/Documentation/xterm-linux.xpm
new file mode 100644
index 000000000..f469c1a18
--- /dev/null
+++ b/Documentation/xterm-linux.xpm
@@ -0,0 +1,61 @@
+/* XPM */
+/*****************************************************************************/
+/**       This pixmap was made by Torsten Poulin - 1996 - torsten@diku.dk   **/
+/**       It was made by combining xterm-blank.xpm with                     **/
+/**       the wonderfully cute Linux penguin mascot by Larry Ewing.         **/
+/**       I had to change Larry's penguin a little to make it fit.          **/
+/**       xterm-blank.xpm contained the following comment:                  **/
+/**       This pixmap is kindly offered by Ion Cionca - 1992 -              **/
+/**       Swiss Federal Institute of Technology                             **/
+/**       Central Computing Service                                         **/
+/*****************************************************************************/
+static char * image_name [] = {
+/**/
+"64 38 8 1",
+/**/
+" 	s mask	c none",
+".	c gray70",
+"X	c gray85",
+"o	c gray50",
+"O	c yellow",
+"+	c darkolivegreen",
+"@	c white",
+"#	c black",
+"              ######                                            ",
+"             ########                                           ",
+"            ##########    ...........................           ",
+"            ###########  .XXXXXXXXXXXXXXXXXXXXXXXXXXX.          ",
+"            ########### .XXXXXXXXXXXXXXXXXXXXXXXXXXXXXoo        ",
+"            #@@@#@@@### .XX+++++++++++++++++++++++XXXXoo        ",
+"            #@#@#@#@### .XX++++++++++++++++++++++++XXXooo       ",
+"            #@#####@### .XX++@@+@++@+@@@@++@+++++++XXXooo       ",
+"            ###OOO######.XX++++++++++++++++++++++++XXXoooo      ",
+"            ##OOOOOO####.XX++@@@@+@@+@@@+++++++++++XXXoooo      ",
+"            #O#OOO#O####.XX++++++++++++++++++++++++XXXooooo     ",
+"            ##O###OO####.XX++@@@@@@@@@@+@@@@@++++++XXXooooo     ",
+"            ###OOOO@#####XX++++++++++++++++++++++++XXXooooo     ",
+"           ##@###@@@@####XX++@@@+@@@@+@@++@@@++++++XXXooooo     ",
+"           #@@@@@@@@@@####X++++++++++++++++++++++++XXXooooo     ",
+"          ##@@@@@@@@@@#####++@+++++++++++++++++++++XXXooooo     ",
+"         ###@@@@@@@@@@######+++++++++++++++++++++++XXXooooo     ",
+"        ####@@@@@@@@@@@#####+@@@@+@+@@@+@++++++++++XXXooooo     ",
+"        ###@@@@@@@@@@@@######++++++++++++++++++++++XXXooooo     ",
+"        ##@@@@@@@@@@@@@@#####@+@@@@++++++++++++++++XXXooooo     ",
+"       ###@@@@@@@@@@@@@@######++++++++++++++++++++XXXXoooo      ",
+"       ###@@@@@@@@@@@@@@######XXXXXXXXXXXXXXXXXXXXXXXXooo       ",
+"      ###@@@@@@@@@@@@@@@######XXXXXXXXXXXXXXXXXXXXXXXooo        ",
+"      ###@@@@@@@@@@@@@@@@#####ooooooooooooooooooooooo...oo      ",
+"      ###@@@@@@@@@@@@@@@######.........................ooo      ",
+"     #OO##@@@@@@@@@@@@@#######oooooooooooooooooooooooooooo      ",
+"     #OOO##@@@@@@@@@@@#OO####O#XXXXXXXXXXXXXXXXXXXXXXXoooo.. .. ",
+"  ###OOOOO##@@@@@@@@@@#OOO#OOO#XXXXXXXXXXXXXX#######XXoooo  .  .",
+" #OOOOOOOO###@@@@@@@@@#OOOOOOO#ooooooooooooooooooooXXXooo     . ",
+" #OOOOOOOOO###@@@@@@@@@#OOOOOOO##XXXXXXXXXXXXXXXXXooooo      .  ",
+"  #OOOOOOOOO#@@@@@@@@###OOOOOOOOO#XXXXXXXXXXXXXXXoo      oooooo ",
+"  #OOOOOOOOO#@@@@@@@####OOOOOOOO#@@@@@@@@@@@XXXXXoo   ooooo...o ",
+" #OOOOOOOOOOO###########OOOOOO##XXXXXXXXXXXXXXXXoo   ooXXXoo..o ",
+"  ##OOOOOOOOO###########OOOO##@@@@@@@@@@@@@XXXXoo    oXXXXX..o  ",
+"     ###OOOO###    oXX##OOO#XXXXXXXXXXXXXXXXXXoo     o.....oo   ",
+"         ####      oooo####oooooooooooooooooooo      ooooooo    ",
+"                                                                ",
+"                                                                "};