add directory Linux-0.97

Linux-0.97/sources/sbin/cdrom/cdrom.README

@@ -0,0 +1,201 @@
+                ANNOUNCING - CDROM support for linux (beta 0.2).
+
+        CDROM support for linux is now ready for beta testing.  You
+must have a CDROM drive, a SCSI adapter and a ISO9660 format disc
+before this will be of any use to you.  You will also need to have the
+source tree for linux 0.97 kernel sources available.  This will work with
+either 0.97 or 0.97pl1, but pl1 is probably better mainly because it handles
+memory better (unrelated to the CDROM, but still an important point).
+
+        This project was a team effort.  The SCSI work was done by
+David Giller rafetmad@cheshire.oxy.edu, and the filesystem was written
+by Eric Youngdale eric@tantalus.nrl.navy.mil.  So far, the code has been
+tested with an aha1542 SCSI card and both NEC and Sony CDROM drives.
+A number of different discs have been tested.
+
+        To install, unpack the archive in your linux kernel directory 
+(usually /usr/src.  This will add a number of new files to the linux
+source tree).  You will then need to apply the patches found in cdrom.diff
+with the following command:
+
+patch -p0 < cdrom.diff
+ 
+and then build the kernel.  Once you have booted the system, you will need
+to add a device with major=11, minor=0 for the first cdrom drive, minor=1 for
+the second and so forth.  You can use a command something like:
+
+        mknod -m 500 /dev/cdrom b 11 0
+
+To mount a disc, use a command something like:
+
+        mount -t iso9660 /dev/cdrom /mnt
+
+I would be interested in hearing about any successes or failures with this
+code.
+
+CHANGES SINCE 0.1:
+
+        Error detection/correction have been improved.  You should not
+get any more multiply queued commands, and I increased the timeout
+period such that the drive no longer times out.  My drive is fairly
+fast, so other drives may have timeout problems.  I need to know this
+so that I can increase the timeout period to a workable value for all
+drives.  The error detection/correction should be pretty solid now.
+
+        Support for Rock Ridge extensions has been added to the filesystem.
+This means:
+
+        * Longer filenames (My implementation limits it to 256 chars).
+        * Mixed case filenames, Normal unix syntax availible. 
+        * Files have correct modes, number of links, and uid/gid
+        * Separate times for atime, mtime, and ctime.
+        * Symbolic links.
+        * Block and Character devices (Untested).
+        * Deep directories (Untested).
+
+        I was able to implement this because Adam Richter was kind
+enough to lend me the Andrew Toolkit disc, which has the Rock Ridge
+extensions.  I should point out that the block and character devices
+and the deep directories have not been tested, since they do not
+appear on the disc that I have.  If anyone has some pre-mastering software,
+and could throw together a *very* small volume (i.e. one floppy disc)
+that has some of these things, I could use the floppy to test and debug
+these features.
+
+        A single element cache was added that sits between the readdir
+function and the lookup function.  Many programs that traverse the
+directory tree (i.e. ls) also need to know the inode number and find
+information about the file from the inode table.  For the CDROM this
+is kind of silly, since all of the information is in one place, but we
+have to make it look kind of like unix.  Thus the readdir function
+returns a name, and then we do a stat, given that name and have to
+search the same directory again for the file that we just extracted in
+readdir.  On the Andrew toolkit disc, there is one directory that
+contains about 700 files and is nearly 80kb long - doing an ls -l in
+that directory takes several minutes, because each lookup has to
+search the directory.  Since it turns out that we often call lookup
+just after we read the directory, I added a one element cache to save
+enough information so as to eliminate the need to search the directory
+again.
+
+        Scatter-gather for the cdrom is now enabled.  This should lead
+to slightly faster I/O.
+
+
+KNOWN PROBLEMS:
+
+        None.
+
+             ********************************************
+
+Some general comments are in order:
+
+        On some drives, there is a feature where the drive can be
+locked under software control to essentially deactivate the eject
+button.  The iso9660 filesystem activates this feature on drives so
+equipt, so you may be unable to remove the disc while it is mounted.
+The eject button will be re-enabled once the disc is dismounted.
+
+        Since it is impossible to corrupt a CDROM, it is unlikely that
+a bug in the iso9660 filesystem will lead to data corruption on your
+hard disk, with the possible exception of files copied from the CDROM
+to the hard disk.  Nonetheless, it is a good idea to have a backup or
+your hard disk, just in case.  Then again, I really did not need to
+say that, did I :-)
+
+        There were several bugs in error handling in the scsi code.
+Previously when a command failed, the higher level drivers would not
+receive the correct sense data from the failed command, or would misinterpret
+the data that they did get.  These has been fixed.
+
+        Up until now, SCSI devices were either discs or tapes (and the
+tapes have not been fully implemented).  CDROM drives are now a third
+category.  There are several reasons why we do not want to treat then
+the same as a regular hard disk, and it was cleaner to make a third
+type of device.  One reason was that.....
+
+        The CDROM has a sector size of 2048 bytes, but the buffer
+cache has buffer sizes of 1024 bytes.  The SCSI high level driver for
+the cdrom must perform buffering of all of the I/O in order to satisfy
+the request.  At some point in the near future support will be present
+in the kernel for buffers in the buffer cache which are != 1024 bytes,
+at which time this code will be remove.
+
+        Only the ISO 9660 filesystem is supported.  High Sierra is not
+supported.  The High Sierra format is just an earlier version of
+ISO9660, but there are minor differences between the two.  Sometimes
+people use the two names interchangably, but nearly all newer discs
+are the ISO9660 format.  It would not be that difficult to support HS,
+but I doubt that there are very many HS discs are out there.  I will
+add this if there is demand for it.
+
+        The inode numbers for files are essentially just the byte
+offset of the beginning of the directory record from the start of the
+disc.  A disc can only hold about 660 MB, so the inode numbers will
+be somewhere between about 60K and 660M.   Any tool that performs
+a stat() on the CDROM obviously needs to be recompiled if it was
+compiled before 32 bit inode support was in the kernel.
+
+        A number of ioctl functions have been provided, some of which
+are only of use when trying to play an audio disc.  An attempt has
+been made to make the ioctls compatible with the ioctls on a Sun, but
+we have been unable to get any of the audio functions to work.  My
+NEC drive and David's Sony reject all of these commands, and we currently
+believe that both of these drives implement the audio functions using
+vendor-specific command codes rather than the universal ones specified
+in the SCSI-II specifications.
+
+        The filesystem has been tested under a number of conditions,
+and has proved to be quite reliable so far.  This filesystem is
+considerably simpler than a read/write filesystem (Files are
+contiguous, so no file allocation tables need to be maintained, there
+is no free space map, and we do not need to know how to rename, create
+or delete files).
+
+        Text files on a CDROM can have several types of line
+terminators.  Lines can be terminated by LF, CRLF, or a CR.  The
+filesystem scans the first 1024 bytes of the file, searching for out
+of band characters (i.e. > 0x80 or some control characters), and if it
+finds these it assumes the the file is a binary format.  If there are
+no out of band characters the filesystem will assume that the file is
+a text file (keeping track of whether the lines are terminated by a
+CR, CRLF, or LF), and automatically converts the line terminators to a
+LF, which is the unix standard.  In the case of CRLF termination, the
+CR is converted to a ' '.
+
+
+                  ***************************************
+                  ***************************************
+
+The remaining comments *only* apply to discs *without* the Rock Ridge
+extensions:
+
+        The find command does not work without the -noleaf switch.
+The reason for this is that the number of links for each directory file
+is not easily obtainable, so it is set to 2.  The default behavior for
+the find program is to look for (i_links-2) subdirectories in each
+directory, and it then assumes that the rest are regular files.  The
+-noleaf switch disables this optimization.
+
+        The filesystem currently has the execute permission set for
+any non-directory file that does not have a period in its name.  This
+is a crude assumption for now, but it kind of works.  There is not an
+easy way of telling whether a file should be executable or not.
+Theoretically it is possible to read the file itself and check for a
+magic number, but this would considerably degrade performance.
+
+        The filesystem does not support block or character devices,
+fifos, or symbolic links.  Also, the setuid bit is never set for any
+program.  The main reason for this is that there is no information in
+the directory entry itself which could be used to indicate these
+special types of files.
+
+        Filenames under ISO9660 are normally all upper case on the
+disc but the filesystem maps these to all lower case.  The filenames
+on the disc also have a version number (like VMS) which appears at the
+end of the filename, and is separated from the rest of the filename by
+a ';' character.  The filesystem strips the version numbers from the
+filename if the version number is 1, and replaces the ';' by a '.' if
+the version number is >1.
+
+eric@tantalus.nrl.navy.mil

Linux-0.97/sources/sbin/cdrom/cdrom.README-02

@@ -0,0 +1,201 @@
+                ANNOUNCING - CDROM support for linux (beta 0.2).
+
+        CDROM support for linux is now ready for beta testing.  You
+must have a CDROM drive, a SCSI adapter and a ISO9660 format disc
+before this will be of any use to you.  You will also need to have the
+source tree for linux 0.97 kernel sources available.  This will work with
+either 0.97 or 0.97pl1, but pl1 is probably better mainly because it handles
+memory better (unrelated to the CDROM, but still an important point).
+
+        This project was a team effort.  The SCSI work was done by
+David Giller rafetmad@cheshire.oxy.edu, and the filesystem was written
+by Eric Youngdale eric@tantalus.nrl.navy.mil.  So far, the code has been
+tested with an aha1542 SCSI card and both NEC and Sony CDROM drives.
+A number of different discs have been tested.
+
+        To install, unpack the archive in your linux kernel directory 
+(usually /usr/src.  This will add a number of new files to the linux
+source tree).  You will then need to apply the patches found in cdrom.diff
+with the following command:
+
+patch -p0 < cdrom.diff
+ 
+and then build the kernel.  Once you have booted the system, you will need
+to add a device with major=11, minor=0 for the first cdrom drive, minor=1 for
+the second and so forth.  You can use a command something like:
+
+        mknod -m 500 /dev/cdrom b 11 0
+
+To mount a disc, use a command something like:
+
+        mount -t iso9660 /dev/cdrom /mnt
+
+I would be interested in hearing about any successes or failures with this
+code.
+
+CHANGES SINCE 0.1:
+
+        Error detection/correction have been improved.  You should not
+get any more multiply queued commands, and I increased the timeout
+period such that the drive no longer times out.  My drive is fairly
+fast, so other drives may have timeout problems.  I need to know this
+so that I can increase the timeout period to a workable value for all
+drives.  The error detection/correction should be pretty solid now.
+
+        Support for Rock Ridge extensions has been added to the filesystem.
+This means:
+
+        * Longer filenames (My implementation limits it to 256 chars).
+        * Mixed case filenames, Normal unix syntax availible. 
+        * Files have correct modes, number of links, and uid/gid
+        * Separate times for atime, mtime, and ctime.
+        * Symbolic links.
+        * Block and Character devices (Untested).
+        * Deep directories (Untested).
+
+        I was able to implement this because Adam Richter was kind
+enough to lend me the Andrew Toolkit disc, which has the Rock Ridge
+extensions.  I should point out that the block and character devices
+and the deep directories have not been tested, since they do not
+appear on the disc that I have.  If anyone has some pre-mastering software,
+and could throw together a *very* small volume (i.e. one floppy disc)
+that has some of these things, I could use the floppy to test and debug
+these features.
+
+        A single element cache was added that sits between the readdir
+function and the lookup function.  Many programs that traverse the
+directory tree (i.e. ls) also need to know the inode number and find
+information about the file from the inode table.  For the CDROM this
+is kind of silly, since all of the information is in one place, but we
+have to make it look kind of like unix.  Thus the readdir function
+returns a name, and then we do a stat, given that name and have to
+search the same directory again for the file that we just extracted in
+readdir.  On the Andrew toolkit disc, there is one directory that
+contains about 700 files and is nearly 80kb long - doing an ls -l in
+that directory takes several minutes, because each lookup has to
+search the directory.  Since it turns out that we often call lookup
+just after we read the directory, I added a one element cache to save
+enough information so as to eliminate the need to search the directory
+again.
+
+        Scatter-gather for the cdrom is now enabled.  This should lead
+to slightly faster I/O.
+
+
+KNOWN PROBLEMS:
+
+        None.
+
+             ********************************************
+
+Some general comments are in order:
+
+        On some drives, there is a feature where the drive can be
+locked under software control to essentially deactivate the eject
+button.  The iso9660 filesystem activates this feature on drives so
+equipt, so you may be unable to remove the disc while it is mounted.
+The eject button will be re-enabled once the disc is dismounted.
+
+        Since it is impossible to corrupt a CDROM, it is unlikely that
+a bug in the iso9660 filesystem will lead to data corruption on your
+hard disk, with the possible exception of files copied from the CDROM
+to the hard disk.  Nonetheless, it is a good idea to have a backup or
+your hard disk, just in case.  Then again, I really did not need to
+say that, did I :-)
+
+        There were several bugs in error handling in the scsi code.
+Previously when a command failed, the higher level drivers would not
+receive the correct sense data from the failed command, or would misinterpret
+the data that they did get.  These has been fixed.
+
+        Up until now, SCSI devices were either discs or tapes (and the
+tapes have not been fully implemented).  CDROM drives are now a third
+category.  There are several reasons why we do not want to treat then
+the same as a regular hard disk, and it was cleaner to make a third
+type of device.  One reason was that.....
+
+        The CDROM has a sector size of 2048 bytes, but the buffer
+cache has buffer sizes of 1024 bytes.  The SCSI high level driver for
+the cdrom must perform buffering of all of the I/O in order to satisfy
+the request.  At some point in the near future support will be present
+in the kernel for buffers in the buffer cache which are != 1024 bytes,
+at which time this code will be remove.
+
+        Only the ISO 9660 filesystem is supported.  High Sierra is not
+supported.  The High Sierra format is just an earlier version of
+ISO9660, but there are minor differences between the two.  Sometimes
+people use the two names interchangably, but nearly all newer discs
+are the ISO9660 format.  It would not be that difficult to support HS,
+but I doubt that there are very many HS discs are out there.  I will
+add this if there is demand for it.
+
+        The inode numbers for files are essentially just the byte
+offset of the beginning of the directory record from the start of the
+disc.  A disc can only hold about 660 MB, so the inode numbers will
+be somewhere between about 60K and 660M.   Any tool that performs
+a stat() on the CDROM obviously needs to be recompiled if it was
+compiled before 32 bit inode support was in the kernel.
+
+        A number of ioctl functions have been provided, some of which
+are only of use when trying to play an audio disc.  An attempt has
+been made to make the ioctls compatible with the ioctls on a Sun, but
+we have been unable to get any of the audio functions to work.  My
+NEC drive and David's Sony reject all of these commands, and we currently
+believe that both of these drives implement the audio functions using
+vendor-specific command codes rather than the universal ones specified
+in the SCSI-II specifications.
+
+        The filesystem has been tested under a number of conditions,
+and has proved to be quite reliable so far.  This filesystem is
+considerably simpler than a read/write filesystem (Files are
+contiguous, so no file allocation tables need to be maintained, there
+is no free space map, and we do not need to know how to rename, create
+or delete files).
+
+        Text files on a CDROM can have several types of line
+terminators.  Lines can be terminated by LF, CRLF, or a CR.  The
+filesystem scans the first 1024 bytes of the file, searching for out
+of band characters (i.e. > 0x80 or some control characters), and if it
+finds these it assumes the the file is a binary format.  If there are
+no out of band characters the filesystem will assume that the file is
+a text file (keeping track of whether the lines are terminated by a
+CR, CRLF, or LF), and automatically converts the line terminators to a
+LF, which is the unix standard.  In the case of CRLF termination, the
+CR is converted to a ' '.
+
+
+                  ***************************************
+                  ***************************************
+
+The remaining comments *only* apply to discs *without* the Rock Ridge
+extensions:
+
+        The find command does not work without the -noleaf switch.
+The reason for this is that the number of links for each directory file
+is not easily obtainable, so it is set to 2.  The default behavior for
+the find program is to look for (i_links-2) subdirectories in each
+directory, and it then assumes that the rest are regular files.  The
+-noleaf switch disables this optimization.
+
+        The filesystem currently has the execute permission set for
+any non-directory file that does not have a period in its name.  This
+is a crude assumption for now, but it kind of works.  There is not an
+easy way of telling whether a file should be executable or not.
+Theoretically it is possible to read the file itself and check for a
+magic number, but this would considerably degrade performance.
+
+        The filesystem does not support block or character devices,
+fifos, or symbolic links.  Also, the setuid bit is never set for any
+program.  The main reason for this is that there is no information in
+the directory entry itself which could be used to indicate these
+special types of files.
+
+        Filenames under ISO9660 are normally all upper case on the
+disc but the filesystem maps these to all lower case.  The filenames
+on the disc also have a version number (like VMS) which appears at the
+end of the filename, and is separated from the rest of the filename by
+a ';' character.  The filesystem strips the version numbers from the
+filename if the version number is 1, and replaces the ';' by a '.' if
+the version number is >1.
+
+eric@tantalus.nrl.navy.mil

Linux-0.97/sources/sbin/cdrom/cdrom.README-05

@@ -0,0 +1,243 @@
+
+		ANNOUNCING - CDROM support for linux (beta 0.5).
+
+	CDROM support for linux is now ready for beta testing.  You
+must have a CDROM drive, a SCSI adapter and a ISO9660 format disc
+before this will be of any use to you.  You will also need to have the
+source tree for linux 0.97, patch level 5 kernel sources available.
+
+	With the patch level 5 kernel, the scsi cdrom support is now in the
+distribution, so there are no longer any special scsi patches for the
+cdrom.  The filesystem is not yet a part of the kernel because it is eventually
+envisioned (by Linus) that this will be installable at run time once the
+installable driver/filesystem code is working in the kernel.
+
+	To install, unpack the archive in your linux kernel directory 
+(usually /usr/src.  This will add a number of new files to the linux
+source tree).  You will then need to apply the patches found in cdrom.diff
+with the following command:
+
+patch -p0 < cdrom.diff
+ 
+and then build the kernel.  Once you have booted the system, you will need
+to add a device with major=11, minor=0 for the first cdrom drive, minor=1 for
+the second and so forth.  You can use a command something like:
+
+	mknod -m 500 /dev/cdrom b 11 0
+
+To mount a disc, use a command something like:
+
+	mount -t iso9660 /dev/cdrom /mnt
+
+I would be interested in hearing about any successes or failures with this
+code.
+
+CHANGES SINCE 0.4:
+
+	No functional changes to filesystem, scsi code is now part of
+distribution kernel as of pl5.
+
+CHANGES SINCE 0.3:
+
+	The main difference is that the filesystem has been updated to
+work with 0.97pl4.
+
+	Also, one new mount option has been added, "norock", which will
+inhibit the rock ridge protocol.
+
+CHANGES SINCE 0.2:
+
+	Support has been added for the older (and now obsolete) variant
+of the iso9660 filesystem, which is known as High Sierra.  There are apparently
+a number of discs still out there that are in this format, and High Sierra
+is actually nearly identical to iso9660, so I added support.
+
+	Mount options have been added which can disable filename mapping,
+and control the conversion of text files.  The options are
+
+	map=off
+	map=normal
+	conv=binary
+	conv=text
+	conv=mtext
+
+The effect that these options have is described later on in this document.
+
+	One small scsi error was fixed which would result in the driver
+hanging if there were an unusual error of any kind.
+
+CHANGES SINCE 0.1:
+
+	Error detection/correction have been improved.  You should not
+get any more multiply queued commands, and I increased the timeout
+period such that the drive no longer times out.  My drive is fairly
+fast, so other drives may have timeout problems.  I need to know this
+so that I can increase the timeout period to a workable value for all
+drives.  The error detection/correction should be pretty solid now.
+
+	Support for Rock Ridge extensions has been added to the filesystem.
+This means:
+
+	* Longer filenames (My implementation limits it to 256 chars).
+	* Mixed case filenames, Normal unix syntax availible. 
+	* Files have correct modes, number of links, and uid/gid
+	* Separate times for atime, mtime, and ctime.
+	* Symbolic links.
+	* Block and Character devices (Untested).
+	* Deep directories (Untested).
+
+	I was able to implement this because Adam Richter was kind
+enough to lend me the Andrew Toolkit disc, which has the Rock Ridge
+extensions.  I should point out that the block and character devices
+and the deep directories have not been tested, since they do not
+appear on the disc that I have.  If anyone has some pre-mastering software,
+and could throw together a *very* small volume (i.e. one floppy disc)
+that has some of these things, I could use the floppy to test and debug
+these features.
+
+	A single element cache was added that sits between the readdir
+function and the lookup function.  Many programs that traverse the
+directory tree (i.e. ls) also need to know the inode number and find
+information about the file from the inode table.  For the CDROM this
+is kind of silly, since all of the information is in one place, but we
+have to make it look kind of like unix.  Thus the readdir function
+returns a name, and then we do a stat, given that name and have to
+search the same directory again for the file that we just extracted in
+readdir.  On the Andrew toolkit disc, there is one directory that
+contains about 700 files and is nearly 80kb long - doing an ls -l in
+that directory takes several minutes, because each lookup has to
+search the directory.  Since it turns out that we often call lookup
+just after we read the directory, I added a one element cache to save
+enough information so as to eliminate the need to search the directory
+again.
+
+	Scatter-gather for the cdrom is now enabled.  This should lead
+to slightly faster I/O.
+
+
+KNOWN PROBLEMS:
+
+	None.
+
+             ********************************************
+
+Some general comments are in order:
+
+	On some drives, there is a feature where the drive can be
+locked under software control to essentially deactivate the eject
+button.  The iso9660 filesystem activates this feature on drives so
+equipt, so you may be unable to remove the disc while it is mounted.
+The eject button will be re-enabled once the disc is dismounted.
+
+	Since it is impossible to corrupt a CDROM, it is unlikely that
+a bug in the iso9660 filesystem will lead to data corruption on your
+hard disk, with the possible exception of files copied from the CDROM
+to the hard disk.  Nonetheless, it is a good idea to have a backup or
+your hard disk, just in case.  Then again, I really did not need to
+say that, did I :-)
+
+	There were several bugs in error handling in the scsi code.
+Previously when a command failed, the higher level drivers would not
+receive the correct sense data from the failed command, or would misinterpret
+the data that they did get.  These has been fixed.
+
+	Up until now, SCSI devices were either discs or tapes (and the
+tapes have not been fully implemented).  CDROM drives are now a third
+category.  There are several reasons why we do not want to treat then
+the same as a regular hard disk, and it was cleaner to make a third
+type of device.  One reason was that.....
+
+	The CDROM has a sector size of 2048 bytes, but the buffer
+cache has buffer sizes of 1024 bytes.  The SCSI high level driver for
+the cdrom must perform buffering of all of the I/O in order to satisfy
+the request.  At some point in the near future support will be present
+in the kernel for buffers in the buffer cache which are != 1024 bytes,
+at which time this code will be remove.
+
+	Both the ISO 9660 filesystem and the High Sierra are
+supported.  The High Sierra format is just an earlier version of
+ISO9660, but there are minor differences between the two.  Sometimes
+people use the two names interchangably, but nearly all newer discs
+are the ISO9660 format.
+
+	The inode numbers for files are essentially just the byte
+offset of the beginning of the directory record from the start of the
+disc.  A disc can only hold about 660 MB, so the inode numbers will
+be somewhere between about 60K and 660M.   Any tool that performs
+a stat() on the CDROM obviously needs to be recompiled if it was
+compiled before 32 bit inode support was in the kernel.
+
+	A number of ioctl functions have been provided, some of which
+are only of use when trying to play an audio disc.  An attempt has
+been made to make the ioctls compatible with the ioctls on a Sun, but
+we have been unable to get any of the audio functions to work.  My
+NEC drive and David's Sony reject all of these commands, and we currently
+believe that both of these drives implement the audio functions using
+vendor-specific command codes rather than the universal ones specified
+in the SCSI-II specifications.
+
+	The filesystem has been tested under a number of conditions,
+and has proved to be quite reliable so far.  This filesystem is
+considerably simpler than a read/write filesystem (Files are
+contiguous, so no file allocation tables need to be maintained, there
+is no free space map, and we do not need to know how to rename, create
+or delete files).
+
+	Text files on a CDROM can have several types of line
+terminators.  Lines can be terminated by LF, CRLF, or a CR.  The
+filesystem scans the first 1024 bytes of the file, searching for out
+of band characters (i.e. > 0x80 or some control characters), and if it
+finds these it assumes the the file is a binary format.  If there are
+no out of band characters the filesystem will assume that the file is
+a text file (keeping track of whether the lines are terminated by a
+CR, CRLF, or LF), and automatically converts the line terminators to a
+LF, which is the unix standard.  In the case of CRLF termination, the
+CR is converted to a ' '.  The heuristic can be explicitly overridden
+with the conv= mount option, which tells the filesystem that *all* files
+on the volume are the specified type.
+
+	Rock Ridge extensions can be inhibited with the "norock" mount
+option.  This could be of use if you have scripts that work with the
+non-Rock Ridge filenames, or if you encounter a bug in the filesystem
+which really screws you up.
+
+
+                  ***************************************
+                  ***************************************
+
+The remaining comments *only* apply to discs *without* the Rock Ridge
+extensions:
+
+	The find command does not work without the -noleaf switch.
+The reason for this is that the number of links for each directory file
+is not easily obtainable, so it is set to 2.  The default behavior for
+the find program is to look for (i_links-2) subdirectories in each
+directory, and it then assumes that the rest are regular files.  The
+-noleaf switch disables this optimization.
+
+	The filesystem currently has the execute permission set for
+any non-directory file that does not have a period in its name.  This
+is a crude assumption for now, but it kind of works.  There is not an
+easy way of telling whether a file should be executable or not.
+Theoretically it is possible to read the file itself and check for a
+magic number, but this would considerably degrade performance.
+
+	The filesystem does not support block or character devices,
+fifos, or symbolic links.  Also, the setuid bit is never set for any
+program.  The main reason for this is that there is no information in
+the directory entry itself which could be used to indicate these
+special types of files.
+
+	Filenames under ISO9660 are normally all upper case on the
+disc but the filesystem maps these to all lower case.  The filenames
+on the disc also have a version number (like VMS) which appears at the
+end of the filename, and is separated from the rest of the filename by
+a ';' character.  The filesystem strips the version numbers from the
+filename if the version number is 1, and replaces the ';' by a '.' if
+the version number is >1.  The mount option map=off will disable all
+of the name mapping, and when this is in effect, all filenames will be
+in upper case, and the semicolons and version numbers will always appear.
+
+eric@tantalus.nrl.navy.mil
+ericy@gnu.ai.mit.edu
+

Linux-0.97/sources/sbin/mount-0.97.README

@@ -0,0 +1,35 @@
+mount/umount/swapon/swapoff(8) for Linux 0.97.3
+===============================================
+
+The most significant improvement over the first release is the repair of
+at least a half dozen really dumb bugs, mostly involving null pointers. 
+These bugs caused frequent core dumps and really made the code unusable.
+
+Some race conditions in the lock handling code have been removed.
+
+Swapoff is available for 0.97.3 and later kernels.
+
+Swapon supports multiple swap files.  In particular, swapon -a will try
+to enable swapping on all the swap entries in /etc/fstab.
+
+File system specific mount options are now supported.  This is of particular
+utility with Werner Almesberger's msdos fs.
+
+Umount -a now reads /etc/mtab instead of /etc/fstab (thanks to David
+Engel for a valuable discussion on this and other points).  In addition,
+it umounts the entries in reverse order, ensuring that it tries to umount
+/usr/spool before /usr, for instance.
+
+Mount will now print mtab for ordinary users as well as for the superuser.
+Several people pointed out this deficiency, and it was a real no-brainer
+that broke it in the first release.
+
+Thanks to Linus, for another great release.  0.97.3 compiled the first time
+out and is working flawlessly.  Thanks also to Ross Biro, for his work on
+Linux TCP/IP which has made it much easier to get this little thing off my
+machine.  Special thanks to everyone who put up with my bugs.
+
+Brickbats etc. to
+
+Doug Quale
+quale@saavik.cs.wisc.edu

Linux-0.97/sources/sbin/mount-0.97.patch

@@ -0,0 +1,57 @@
+Well, mount(8) is still disaster.  Already I have reports of two problems.
+
+1) It won't compile.  This has the advantage that you'll never see any
+other bugs, but it does reduce its usefulness somewhat.  The mount(2)
+prototype I used in sys/mount.h and in the _syscall5 in mount.c doesn't
+agree with <unistd.h>.  The easy fix is to comment out the prototype in
+<unistd.h>, the better fix is to correct my prototypes by adding the
+const qualifier to the final parameter of mount(2) in both places.
+
+2) The root entry doesn't get added to the mtab when the mtab is missing.
+This used to work right, and the patch below makes it work again.
+
+
+--- 1.1	1992/09/06 13:30:53
++++ mount.c	1992/09/06 23:57:19
+@@ -15,7 +15,7 @@
+ #include <unistd.h>
+ 
+ _syscall5(int, mount, const char *, special, const char *, dir,
+-	   const char *, type, unsigned long, flags, void *, data);
++	   const char *, type, unsigned long, flags, const void *, data);
+ #endif
+ 
+ 
+--- 1.1	1992/09/06 13:30:53
++++ sundries.c	1992/09/06 23:57:20
+@@ -153,6 +153,7 @@
+       if (addmntent (F_mtab, fstab) == 1)
+ 	die (1, "mount: error writing %s: %s", MOUNTED, strerror (errno));
+     }
++  endmntent (F_mtab);
+ }
+ 
+ /* Open mtab.  */
+@@ -159,8 +160,10 @@
+ void
+ open_mtab (const char *mode)
+ {
+-  if ((F_mtab = setmntent (MOUNTED, mode)) == NULL)
++  if (fopen (MOUNTED, "r") == NULL)
+     create_mtab ();
++  if ((F_mtab = setmntent (MOUNTED, mode)) == NULL)
++    die (2, "can't open %s: %s", MOUNTED, strerror (errno));
+ }
+ 
+ /* Close mtab.  */
+--- sys/mount.h~	Sun Sep  6 08:22:57 1992
++++ sys/mount.h	Sun Sep  6 18:57:20 1992
+@@ -113,7 +113,7 @@
+ #ifdef HAVE_MOUNT5
+ /* 0.96c-pl1 and later we have a five argument mount(2).  */
+ int mount (const char *__special, const char *__dir,
+-	   const char *__type, unsigned long __flags, void *__data);
++	   const char *__type, unsigned long __flags, const void *__data);
+ #else
+ /* Before 0.96c-pl1 we had a four argument mount(2).  */
+ int mount (const char *__special, const char *__dir,

Linux-0.97/sources/system/efs/efsprogs.README

@@ -0,0 +1,164 @@
+		      README file for the ext file system
+
+				Release 0a8
+				 07.09.92
+
+				Remy  Card
+			     (card@masi.ibp.fr)
+
+
+
+	This file documents the ext file system for Linux and the programs
+needed to use this file system
+
+The ext file system
+===================
+
+	The ext file system is an extension of the minix file system to get rid
+of its restrictions.
+
+	The ext file system allows :
+	- varying length file names from 1 to 255 characters,
+	- a maximum of 4 Giga blocks per file system, so the maximum size of
+	  a file system is 4 Tera bytes,
+	- a maximum size of 16 Giga bytes per file,
+	- a free blocks/inodes management with a linked list so no more
+	  disk space is "lost" for bitmaps.
+
+Limitations of the ext file system
+==================================
+
+	The ext file system is not yet finished and some modifications will
+be made in the future.  The current restrictions are :
+	- some functions in the code are not very well written,
+	- the ext file system is only able to manage 1024 bytes blocks.  Some
+	  people are working to allow the Linux buffer cache to manage bigger
+	  blocks.  When it is done, the ext file system will support bigger
+	  blocks.
+
+Status of the ext file system
+=============================
+
+	Since release 0.96c, the ext file system has been integrated in Linux.
+So, there is nothing to modify in the kernel to use this file system.  However,
+this file system is currently in alpha test and may contain some bugs.
+
+How to use the ext file system
+==============================
+
+	To use the ext file system, you have to get linux 0.96c or latter.
+You also need two programs to create a file system and check that it is
+consistent.
+
+	These two programs can be obtained by anonymous FTP on ftp-masi.ibp.fr
+[132.227.64.26] in the file pub/linux/ALPHA/extfs/efsprogs8.tar.Z or on
+tsx-11.mit.edu in the file pub/linux/ALPHA/extfs/efsprogs8.tar.Z.  This
+file contains the source and binary programs (compiled with GCC 2.2.2d and
+linked static) for mkefs (make ext file system) and efsck (ext file system
+check).  You can also take the file efsprogs8.src.tar.Z which contains only the
+source programs or the file efsprogs8.bin.tar.Z which contains only the binary
+programs.
+
+	You also need to get the new mount and df command from the latest
+rootimage.  These two commands now use the Linux VFS layer and can be used
+with any file system integrated in Linux.
+
+	Last, you must recompile every program using the readdir() function 
+with a version of GCC greater than 2.1 (I suggest using GCC 2.2.2d which is the
+"official" C compiler for Linux).  Some programs using readdir() are : the GNU
+fileutils, tar, the shells (bash, tcsh, zsh), ...
+
+Using an ext file system
+========================
+
+	To create an ext file system, you must use the mkefs command. Its
+syntax is :
+	mkefs [-c | -l filename] [-i bytes_per_inode] /dev/hdXX size_in_blocks
+
+	The arguments for mkefs are :
+	-c		tests bad blocks on the file system,
+	-l file		reads the list of bad blocks from the file,
+	-i bpi		specifies the inode ratio.
+
+	To mount an ext file system, you must use the new mount command. The
+syntax is :	mount -t ext /dev/hdXX /dir
+
+	You can also add a line to the file /etc/fstab if you want the ext file
+system to be mounted when the system is booted. The format of this line is :
+	/dev/hdXX	/dir	ext	defaults
+
+	After mounting an ext file system, you can use it by the standard
+Linux commands (ls, rm, cp, mv, ...).
+
+	You can unmount an ext file system by the command :
+		umount /dev/hdXX
+
+	You can check an ext file system by using the efsck command. Its syntax
+is :
+	efsck [-larvsdtS] /dev/hdXX
+
+	The arguments for efsck are :
+	-l		lists all the file names in the file system
+	-a		automaically repairs the file system (use with caution)
+	-r		interactively repairs the file system
+	-v		verbose execution
+	-s		lists the super block informations
+	-d		prints debugging output (not very useful except for me
+			when I try to find bugs in efsck...)
+	-t		tests for bad blocks on the file system
+	-S		salvages the blocks/inodes free lists
+
+Important warnings:
+-------------------
+1/	efsck comes with NO WARRANTY !! I have written it by using the
+minix file system fsck program and it seems to work for me but it has not
+been extensively tested.  I do not know is fsck is able to repair every
+kind of inconsistency.  I suggest that you don't use the -a parameter.
+
+2/	when efsck discovers problems in the free blocks/inodes linked lists,
+it salvages the lists, i.e. rebuilds them.  If efsck rebuilds the lists, there
+may problems if the file system is mounted because a copy of the first free
+block number and first free inode number is kept in memory for mounted file
+systems.  If the lists are salvaged, the first free block and first free inode
+can change and be different from the ones kept in memory.  efsck tries to keep
+the same first free block/inode but it is not always possible.  When one is
+changed, it now prints a warning message.
+
+Future work on the ext fs
+=========================
+
+	I plan to modify the ext file system to add functionalities or
+remove some of its limitations :
+	- be sure that the efsck program is good and fix its bugs if any,
+	- fix bugs reported by alpha-testers,
+	- use bigger blocks as soon as the buffer cache will be able to
+	  manage them, and perhaps use different block sizes in the same
+	  file system (like fragments in BSD).
+
+	The next release of the ext fs won't be compatible with the current
+one, i.e. a current file system won't be managed by the new code.  However,
+the new ext fs will be able to coexist with the current one so transition
+will be easy.  Moreover, a program will be available to convert a current ext
+fs to the new format.
+
+How to report bugs
+==================
+
+	If you encounters a strange behaviour of the ext file system or of
+the mkefs and efsck programs, feel free to report them to me (card@masi.ibp.fr)
+so that I can find the bugs and fix them.  It is also a good idea to report them
+to the KERNEL channel of the mailing list and I will send the fixes to this
+list.
+
+Credits
+=======
+
+	The ext fs code originates in the Minix fs management written by Linus
+Torvalds.  Linus also gave some very good advices during the design of the
+ext fs.
+
+	I'd like to thank all alpha testers who report bugs or success. These
+reports help me to improve the ext fs.
+
+	Last but not least, my acknowledgements go to Wayne Davison who makes
+a good work in mkefs, efsck and the future conversion program.

Linux-0.97/sources/usr.bin/rzsz.README

@@ -0,0 +1,24 @@
+WED Jul 29 20:02:06 MET 1992
+ 
+                        Zmodem v3.18 for Linux
+                        ~~~~~~~~~~~~~~~~~~~~~~
+         Package info: 'rzsz9202.tar-z' patched with ''rzsz9202.dff.Z'
+
+                                   * * *
+Enter 'make' for a list of available targets ('make linux!' for a complete
+installation). Please login as 'root' and ensure that the the directories
+/usr/local/bin , /usr/local/lib and /usr/man/man1 exist.
+The patched sources are ready to compile with GCC 2.2.2. All executables have
+been successfully tested under Linux v0.96c-pl2 .
+
+Note: I've added an environment variable called 'RZSZLINE' that points to your
+serial port device. It's a good idea to define it when you login, so put the
+following statements in your ~/.profile :
+              RZSZLINE=/dev/ttys0 # or whatever
+              export RZSZLINE
+ 
+I'd like to thank Nathan Laredo and Werner Almesberger for their hints and
+suggestions.
+
+Have fun with it.
+--Fabian Mueller, fabi@imp.ch