diff options
Diffstat (limited to 'Documentation')
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 ", +" ", +" "}; |