diff -u --recursive --new-file pre2.0.1/linux/CREDITS linux/CREDITS --- pre2.0.1/linux/CREDITS Sun May 12 10:16:05 1996 +++ linux/CREDITS Sun May 12 21:32:16 1996 @@ -123,6 +123,10 @@ D: Author and maintainer of the QIC-02 tape driver S: The Netherlands +N: Ross Biro +E: bir7@leland.Stanford.Edu +D: Original author of the Linux networking code + N: Thomas Bogendoerfer E: tsbogend@bigbug.franken.de D: Lance32 driver @@ -131,10 +135,6 @@ S: 91452 Wilhermsdorf S: Germany -N: Ross Biro -E: bir7@leland.Stanford.Edu -D: Original author of the Linux networking code - N: Bill Bogstad E: bogstad@cs.jhu.edu D: Wrote /proc/self patch @@ -320,6 +320,16 @@ S: Boulder, Colorado 80302 S: USA +N: Heiko Eissfeldt +E: heiko@colossus.escape.de heiko@unifix.de +D: verify_area stuff, generic scsi fixes +D: SCSI Programming HOWTO +D: POSIX.1 compliance testing +S: Unifix Software GmbH +S: Bueltenweg 27a +S: D-38106 Braunschweig +S: Germany + N: Bjorn Ekwall E: bj0rn@blox.se W: http://www.pi.se/blox/ @@ -583,6 +593,14 @@ S: Chapel Hill, North Carolina 27514-4818 S: USA +N: Bernhard Kaindl +E: bartelt@computerhaus.at +D: Author of a menu based configuration tool, kmenu, which +D: is the predecessor of 'make menuconfig' and 'make xconfig'. +S: Tallak 95 +S: 8103 Rein +S: Austria + N: Fred N. van Kempen E: waltje@uwalt.nl.mugnet.org D: NET-2 @@ -633,6 +651,13 @@ E: rfkoenig@immd4.informatik.uni-erlangen.de D: The Linux Support Team Erlangen +N: Gero Kuhlmann +E: gero@gkminix.han.de +D: mounting root via NFS +S: Donarweg 4 +S: D-30657 Hannover +S: Germany + N: Markus Kuhn E: mskuhn@cip.informatik.uni-erlangen.de W: http://wwwcip.informatik.uni-erlangen.de/user/mskuhn @@ -641,13 +666,6 @@ S: D-91080 Uttenreuth S: Germany -N: Gero Kuhlmann -E: gero@gkminix.han.de -D: mounting root via NFS -S: Donarweg 4 -S: D-30657 Hannover -S: Germany - N: Bas Laarhoven E: bas@vimec.nl D: Loadable modules and ftape driver @@ -986,14 +1004,6 @@ D: Keeper of the Jargon File and curator of the Retrocomputing Museum D: Author, Emacs VC and GUD modes -N: Bernhard Kaindl -E: bartelt@computerhaus.at -D: Author of a menu based configuration tool, kmenu, which -D: is the predecessor of 'make menuconfig' and 'make xconfig'. -S: Tallak 95 -S: 8103 Rein -S: Austria - N: Stefan Reinauer E: stepan@home.culture.mipt.ru W: http://home.culture.mipt.ru/~stepan @@ -1314,14 +1324,6 @@ S: Breeburgsingel 12 S: 2135 CN Hoofddorp S: The Netherlands - -N: Stephen D. Williams -E: sdw@lig.net -E: sdw@meaddata.com -D: Consultant, entrepreneur, developer -S: 2464 Rosina Drive -S: Dayton, Ohio 45342-6430 -S: USA N: G\"unter Windau E: gunter@mbfys.kun.nl diff -u --recursive --new-file pre2.0.1/linux/Documentation/Changes linux/Documentation/Changes --- pre2.0.1/linux/Documentation/Changes Sun May 12 10:16:05 1996 +++ linux/Documentation/Changes Sun May 12 21:36:00 1996 @@ -89,7 +89,7 @@ In the latest 1.3.x kernel releases the /proc file system structure was changed, so you need to upgrade the procps package to version 0.99a. In the very latest kernels, /proc has changed again. There's -not yet an officially updated version of procps, so make due with +not yet an officially updated version of procps, so make do with 0.99a; you might want to look for one of the patches floating around to update 0.99a for use with 1.3.94 and later kernels. diff -u --recursive --new-file pre2.0.1/linux/Documentation/cdrom/cdrom-standard.tex linux/Documentation/cdrom/cdrom-standard.tex --- pre2.0.1/linux/Documentation/cdrom/cdrom-standard.tex Sun May 12 10:16:05 1996 +++ linux/Documentation/cdrom/cdrom-standard.tex Sun May 12 21:36:00 1996 @@ -53,7 +53,7 @@ Apart from the somewhat unstructured interfacing with software, the 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, others not. Some drivers lock the +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 @@ -272,7 +272,7 @@ \subsection{$Disc_status(dev_t\ dev)$} \label{disc status} -As a complement to $drive_status()$, this functions can provide the +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 $dev$. The history of development of the CD's use as a carrier medium for various digital information @@ -288,7 +288,7 @@ 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 +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}. @@ -347,8 +347,8 @@ a disc selection can be made by software. This function should perform disc selection. It should return the number of the selected disc on success, a negative value on error. Currently, none of the \linux\ -\cdrom\ drivers appear to support such functionality, but it defined -here for future purpose. +\cdrom\ drivers appears to support such functionality, but it is defined +here for future purposes. \subsection{$Get_last_session(dev_t\ dev, struct\ cdrom_multisession * ms_info)$} @@ -418,12 +418,13 @@ 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 -oppose, this code then should be standardized in \cdromc). +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 +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: @@ -450,8 +451,8 @@ CDC_PLAY_AUDIO& can perform audio-functions (play, pause, etc)\cr } $$ -The capability flag is declared $const$, to prevent drivers to -accidentally tamper with the contents. However, upon registration, +The capability flag is declared $const$, to prevent drivers from +accidentally tampering with the contents. However, upon registration, some (claimed) capability flags may be cleared if the supporting function has not been implemented (see $register_cdrom()$ in \cdromc). @@ -464,17 +465,17 @@ if\ (cdo\rightarrow capability \mathrel\& \mathord{\sim} cdo\rightarrow mask \mathrel{\&} CDC_) \ldots $$ -The $mask$ could be set in the low-level driver code do disable +The $mask$ could be set in the low-level driver code to disable certain capabilities for special brands of the device that can't -perform the actions. However, there is not (yet) and $ioctl$ to set +perform the actions. However, there is not (yet) an $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 the different users's wishes, hopefully -independently of the ideas of the respectable author that happened to +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: $$ @@ -537,7 +538,7 @@ 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 trough the $flags$ +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 @@ -545,11 +546,11 @@ \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$ as an indication +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 been +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} @@ -564,7 +565,7 @@ \subsection{And what about standards?} -You might hesitate to accept this proposal as is comes from the +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 @@ -583,8 +584,8 @@ differences in behavior of the various drivers, and the need for an $ioctl$ informing about media changes.} -We believe that using $O_NONBLOCK$ as indication for opening a device -for $ioctl$ commanding only, can be easily introduced in the \linux\ +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 @@ -594,7 +595,7 @@ \subsection{The preferred strategy of $open()$} -The routines in \cdromc\ are designed in such way, that a run-time +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: @@ -734,7 +735,7 @@ The following $ioctl$s have been introduced to allow user programs to control the behavior of individual \cdrom\ devices. New $ioctl$ -commands an be identified by their underscores in the name. +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 @@ -757,7 +758,7 @@ \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 + 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 @@ -802,10 +803,10 @@ and return values. \item Rename your $_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, this are just calls +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 deal with audio commands (these are +$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: @@ -828,8 +829,8 @@ Thanks to all the people involved. Thanks to Thomas Quinot, Jon Tombs, Ken Pizzini, Eberhard M\"onkeberg and Andrew Kroll, the \linux\ -\cdrom\ device driver developers that were kind enough to give -sugestions and criticisms during the writing. Finally of course, I +\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. diff -u --recursive --new-file pre2.0.1/linux/Documentation/cdrom/cm206 linux/Documentation/cdrom/cm206 --- pre2.0.1/linux/Documentation/cdrom/cm206 Sun May 12 10:16:05 1996 +++ linux/Documentation/cdrom/cm206 Sun May 12 21:36:00 1996 @@ -6,7 +6,7 @@ Changes since version 0.99 -------------------------- - Interfacing to the kernel is routed though an extra interface layer, - cdrom.c. This allows runtime-configurable `bahavior' of the cdrom-drive, + cdrom.c. This allows runtime-configurable `behavior' of the cdrom-drive, independent of the driver. Features since version 0.33 @@ -70,7 +70,7 @@ 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 in in the kernel, +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 @@ -84,7 +84,7 @@ insmod /usr/src/linux/modules/cm206.o cm206=0x300,11 -The order of base port and irq line don't matter; you may specify only +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. @@ -181,5 +181,5 @@ (c) 1995 David A. van Leeuwen The driver is released under the conditions of the GNU general public -license, that can be found in the file COPYING in the root of this +license, which can be found in the file COPYING in the root of this source tree. diff -u --recursive --new-file pre2.0.1/linux/Documentation/cdrom/ide-cd linux/Documentation/cdrom/ide-cd --- pre2.0.1/linux/Documentation/cdrom/ide-cd Thu Jan 1 02:00:00 1970 +++ linux/Documentation/cdrom/ide-cd Sun May 12 10:19:39 1996 @@ -0,0 +1,416 @@ +IDE-CD driver documentation +10 May 1996 +scott snyder + +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 rudimentary support for cdrom changers which comply + with the ATAPI 2.6 draft standard (such as the NEC CDR-251). This + merely adds a function to switch between the slots of the changer + under control of an external program. A sample such program is + appended to the end of this file. I've heard that the Sanyo 3-disc + changer does not conform to this standard, so the changer functions + will probably not work with that drive. + + +2. Installation +--------------- + +0. The ide-cd relies on the ide disk driver. See + drivers/block/README.ide 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 + drivers/block/README.ide. + +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 drivers/block/README.ide.) + + 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 drivers/block/README.ide 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 `cdload' 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 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