summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/00-INDEX69
-rw-r--r--Documentation/BUG-HUNTING92
-rw-r--r--Documentation/Changes181
-rw-r--r--Documentation/CodingStyle212
-rw-r--r--Documentation/Configure.help3927
-rw-r--r--Documentation/IO-mapping.txt202
-rw-r--r--Documentation/SMP.txt25
-rw-r--r--Documentation/cdrom/00-INDEX29
-rw-r--r--Documentation/cdrom/aztcd810
-rw-r--r--Documentation/cdrom/cdrom-standard.tex971
-rw-r--r--Documentation/cdrom/cdu31a196
-rw-r--r--Documentation/cdrom/cm206185
-rw-r--r--Documentation/cdrom/gscd60
-rw-r--r--Documentation/cdrom/ide-cd512
-rw-r--r--Documentation/cdrom/isp16100
-rw-r--r--Documentation/cdrom/mcd4
-rw-r--r--Documentation/cdrom/mcdx44
-rw-r--r--Documentation/cdrom/optcd57
-rw-r--r--Documentation/cdrom/sbpcd1064
-rw-r--r--Documentation/cdrom/sjcd60
-rw-r--r--Documentation/cdrom/sonycd535121
-rw-r--r--Documentation/devices.tex1270
-rw-r--r--Documentation/devices.txt896
-rw-r--r--Documentation/digiboard.txt155
-rw-r--r--Documentation/exception.txt286
-rw-r--r--Documentation/filesystems/00-INDEX16
-rw-r--r--Documentation/filesystems/affs.txt188
-rw-r--r--Documentation/filesystems/hpfs.txt27
-rw-r--r--Documentation/filesystems/ncpfs.txt12
-rw-r--r--Documentation/filesystems/smbfs.txt13
-rw-r--r--Documentation/filesystems/sysv-fs.txt37
-rw-r--r--Documentation/filesystems/umsdos.txt96
-rw-r--r--Documentation/filesystems/vfat.txt464
-rw-r--r--Documentation/ide.txt482
-rw-r--r--Documentation/initrd.txt286
-rw-r--r--Documentation/ioctl-number.txt108
-rw-r--r--Documentation/isdn/00-INDEX21
-rw-r--r--Documentation/isdn/CREDITS45
-rw-r--r--Documentation/isdn/INTERFACE644
-rw-r--r--Documentation/isdn/README620
-rw-r--r--Documentation/isdn/README.audio119
-rw-r--r--Documentation/isdn/README.icn64
-rw-r--r--Documentation/isdn/README.pcbit40
-rw-r--r--Documentation/isdn/README.syncppp58
-rw-r--r--Documentation/isdn/README.teles73
-rw-r--r--Documentation/isdn/syncPPP.FAQ224
-rw-r--r--Documentation/java.txt111
-rw-r--r--Documentation/locks.txt102
-rw-r--r--Documentation/logo.txt13
-rw-r--r--Documentation/magic-number.txt63
-rw-r--r--Documentation/mandatory.txt152
-rw-r--r--Documentation/modules.txt215
-rw-r--r--Documentation/networking/00-INDEX31
-rw-r--r--Documentation/networking/3c505.txt46
-rw-r--r--Documentation/networking/Configurable33
-rw-r--r--Documentation/networking/alias.txt92
-rw-r--r--Documentation/networking/arcnet-hardware.txt3134
-rw-r--r--Documentation/networking/arcnet.txt506
-rw-r--r--Documentation/networking/ax25.txt55
-rw-r--r--Documentation/networking/framerelay.txt39
-rw-r--r--Documentation/networking/ncsa-telnet16
-rw-r--r--Documentation/networking/net-modules.txt294
-rw-r--r--Documentation/networking/ppp.txt25
-rw-r--r--Documentation/networking/tcp.txt39
-rw-r--r--Documentation/networking/tulip.txt110
-rw-r--r--Documentation/networking/vortex.txt35
-rw-r--r--Documentation/networking/z8530drv.txt654
-rw-r--r--Documentation/nfsroot.txt204
-rw-r--r--Documentation/oops-tracing.txt150
-rw-r--r--Documentation/ramdisk.txt207
-rw-r--r--Documentation/riscom8.txt56
-rw-r--r--Documentation/rtc.txt281
-rw-r--r--Documentation/scsi.txt30
-rw-r--r--Documentation/smp.tex346
-rw-r--r--Documentation/svga.txt268
-rw-r--r--Documentation/unicode.txt139
-rw-r--r--Documentation/watchdog.txt83
-rw-r--r--Documentation/xterm-linux.xpm61
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 ",
+" ",
+" "};