lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory Linux-0.98

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:21:16 -05:00
parent 265896c4ae
commit 56596ada90
13765 changed files with 3471432 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

256
Linux-0.98/sources/sbin/cdrom/README.CDROM-06a Normal file
View File

@@ -0,0 +1,256 @@
ANNOUNCING - CDROM support for linux (beta 0.6a).
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.98pl3 kernel sources available. This
filesystem will not work with a pre pl3 kernel, because one of the arguments
to the iget function changed in pl3, and a new include file is now required.
With the patch level 0.98 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. The door lock/unlock functions are now part of
the stock scsi drivers, so these functions have been removed from the
filesystem.
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.5:
Door locking functions removed from filesystem, since those
operations are now handled automatically by the scsi code.
In inode.c, set a value for s->s_blocksize, so that execve can
execute binaries off of a CDROM.
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

260
Linux-0.98/sources/sbin/cdrom/README.CDROM-98pl4 Normal file
View File

@@ -0,0 +1,260 @@
ANNOUNCING - CDROM support for linux (beta 0.7).
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.98pl4 kernel sources available. This
filesystem will not work with a pre pl4 kernel, because one of the arguments
to the iget function changed in pl4, and a new include file is now required.
With the patch level 0.98 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. The door lock/unlock functions are now part of
the stock scsi drivers, so these functions have been removed from the
filesystem.
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.6:
Various minor changes to mirror changes in the kernel as a whole.
CHANGES SINCE 0.5:
Door locking functions removed from filesystem, since those
operations are now handled automatically by the scsi code.
In inode.c, set a value for s->s_blocksize, so that execve can
execute binaries off of a CDROM.
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

174
Linux-0.98/sources/sbin/cdrom/README.CDROM-98pl6 Normal file
View File

@@ -0,0 +1,174 @@
CDROM support for linux.
Starting with the 0.98.6 kernel, the isofs filesystem is now
part of the official distribution. The filesystem is not compiled
into the kernel by default, however. In order to use it, you
will need to edit the file include/linux/config.h, and go down towards
the bottom, and look for a line like:
#undef ISO9660_FS
change this to:
#define ISO9660_FS
and then build the kernel in the usual fashion, and you should be all
set. You must have a CDROM drive, a SCSI adapter and a ISO9660 format
disc before this will be of any use to you.
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
There are mount options which can disable filename mapping,
and control the conversion of text files. The options are:
map=[on,off,normal]
conv=[auto,binary,text,mtext]
norock
cruft
The defaults are effectively map=on,conv=auto,rock,nocruft.
The effect that these options have is described later on in this document.
Support for Rock Ridge extensions is present in 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.
* Deep directories (Untested).
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 scsi cdrom code 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.
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.
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 removed.
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.
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.
Discs that are mastered by Profit Publishing, Tuscon AZ have
been known to have a defective file length field. For some reason the
top byte contains junk for all I can tell, and this confuses the
iso9660 filesystem. If you run into trouble with discs from Profit, use the
"cruft" mount option, which will cause the filesystem to mask off the top
byte of the file length.
eric@tantalus.nrl.navy.mil

22
Linux-0.98/sources/sbin/cdrom/README.xcdplayer Normal file
View File

@@ -0,0 +1,22 @@
There are two different versions of xcdplayer here, one that
works (or is supposed to work) with scsi-2 drives, and a second
version that will only work with NEC drives.
The NEC version is known to work - I have it going as I type
this. My project for this afternoon is to pick up a couple of little
speakers to put next to my monitor, since my headphone cables are not
quite long enough.
The scsi-2 version would appear to need some work since we are
still missing a couple of kernel ioctl functions. I would like
someone with a scsi-2 drive to pick this up and get it working,
because it is hard for me to do this when I cannot try it out. If you
would like to give it a shot, let me know. I can tell you what needs
to be done, and we may be able to borrow some of the code from the
NEC. The NEC implements all of the ioctls in a user-mode program
which makes use of one special ioctl that lets us format commands and
send them directly to the drive. Ultimately this belongs in the
kernel for the scsi-2 drives.
-Eric

176
Linux-0.98/sources/sbin/lilo/lilo.6.CHANGES Normal file
View File

@@ -0,0 +1,176 @@
Changes from version 5 to 6
---------------------------
Boot sector
-----------
- added command-line argument passing.
- now clears BSS of traditional images too.
- chain.b is now more careful about register values when invoking
the boot sector of the other OS.
- added an interface for externally provided command lines.
- added experimental recognition of linear addresses.
Map installer
-------------
- fixed opening the disktab file. (Using -f didn't work.)
- fixed use of BIOS codes for the map file: the tilde is now appended
before the BIOS code.
- added a chdir("/") when using -r
- added more sanity checks.
- added generation of linear addresses.
Documentation
-------------
- removed all references to swap device settings in the kernel because
recent kernels don't support that any longer.
- added a troubleshooting section.
- several minor fixes and improvements.
Changes from version 4 to 5
---------------------------
Map installer
-------------
- added automatic boot sector backup.
- fixed variable block size detection. (Didn't work with the 0.97-pl2
kernel.)
- added the chroot (-r) option.
- made the partition table part of a foreign OS boot descriptor
optional.
Documentation and installation
------------------------------
- most of README has moved into doc.tex (LaTeX)
- added a utility to activate a partition.
- make install now reminds the user to update the map.
- dd is now used in a more efficient way in the Makefile.
(Fewer subshells, etc.)
Changes from version 3 to 4
---------------------------
Boot sector
-----------
- added a configurable delay.
- added a diagnostic title message.
Map installer
-------------
- fixed all known include file conflicts.
- added support for variable block sizes. (Not used yet.)
- added some more sanity checks.
- added a tool to determine SCSI disk parameters.
Documentation and installation
------------------------------
- extended coverage of SCSI disks.
- make install now backs up chain.b and boot.b of any older LILO
installation. (To say: your system remains bootable even if you
forget to run /etc/lilo/install after the update or if this fails
for some reason.)
- moved the changes section from README into CHANGES.
- a set of pre-compiled executables of lilo, boot.b, chain.b and
dparam.com is available too.
Changes from version 2 to 3
---------------------------
Boot sector
-----------
- can initialize BSS of unstripped kernels.
- also accepts [Tab] to show the list of known images.
Map installer
-------------
- fixed parsing of the root device specification.
- fixed setting of the root device when the boot image doesn't
define it.
- reduced the number of installable images from 19 to 16. (Because the
descriptors have grown.)
Documentation
-------------
- added a booting basics section.
- many minor changes.
Changes from version 1 to 2
---------------------------
Boot sector
-----------
- added command-line editing.
- added debugging support (-DDEBUG).
- added support for compacted maps.
- some cosmetic changes.
Map installer
-------------
- major rewrite.
- files that contain "holes" are now handled properly.
- added map compaction.
- devices are now created on the fly only if they can't be found in /dev.
- improved sanity checking.
- can now boot other operating systems.
- can now boot unstripped kernel executables.
- added support for a disk parameter file.
- reduced the number of installable images from 21 to 19.
- changed the command-line syntax.
- root and boot can now be specified on the command line.
Documentation
-------------
- many changes, including correction of some minor errors.
Changes from version 0 to 1
---------------------------
Boot sector
-----------
- tested as master boot record.
- improved the boot prompt invocation method.
- increased the number of installable images to 21.
- added a help facility.
- improved read error handling and error reporting in the boot loader.
- added a second stage boot loader.
Map installer
-------------
- fixed some minor bugs in the map installer. Removed all compiler
warnings.
- added labeling of images.
- added version checking for the boot sector.
- replaced option -r by -m. -r will be available for a while for
compatibility.
- added booting from device files (that have boot images written on them).
- BIOS device codes can now be specified for boot image files too.
- added concatenation of images. (This is a test feature that will be
changed in the future.)
Documentation
-------------
- some minor documentation errors have been corrected.
- the README now warns that the map has to be rebuilt after the images are
replaced or moved.
- added a files, a hints and an examples section.

176
Linux-0.98/sources/sbin/lilo/lilo.6.CHANGES.txt Normal file
View File

@@ -0,0 +1,176 @@
Changes from version 5 to 6
---------------------------
Boot sector
-----------
- added command-line argument passing.
- now clears BSS of traditional images too.
- chain.b is now more careful about register values when invoking
the boot sector of the other OS.
- added an interface for externally provided command lines.
- added experimental recognition of linear addresses.
Map installer
-------------
- fixed opening the disktab file. (Using -f didn't work.)
- fixed use of BIOS codes for the map file: the tilde is now appended
before the BIOS code.
- added a chdir("/") when using -r
- added more sanity checks.
- added generation of linear addresses.
Documentation
-------------
- removed all references to swap device settings in the kernel because
recent kernels don't support that any longer.
- added a troubleshooting section.
- several minor fixes and improvements.
Changes from version 4 to 5
---------------------------
Map installer
-------------
- added automatic boot sector backup.
- fixed variable block size detection. (Didn't work with the 0.97-pl2
kernel.)
- added the chroot (-r) option.
- made the partition table part of a foreign OS boot descriptor
optional.
Documentation and installation
------------------------------
- most of README has moved into doc.tex (LaTeX)
- added a utility to activate a partition.
- make install now reminds the user to update the map.
- dd is now used in a more efficient way in the Makefile.
(Fewer subshells, etc.)
Changes from version 3 to 4
---------------------------
Boot sector
-----------
- added a configurable delay.
- added a diagnostic title message.
Map installer
-------------
- fixed all known include file conflicts.
- added support for variable block sizes. (Not used yet.)
- added some more sanity checks.
- added a tool to determine SCSI disk parameters.
Documentation and installation
------------------------------
- extended coverage of SCSI disks.
- make install now backs up chain.b and boot.b of any older LILO
installation. (To say: your system remains bootable even if you
forget to run /etc/lilo/install after the update or if this fails
for some reason.)
- moved the changes section from README into CHANGES.
- a set of pre-compiled executables of lilo, boot.b, chain.b and
dparam.com is available too.
Changes from version 2 to 3
---------------------------
Boot sector
-----------
- can initialize BSS of unstripped kernels.
- also accepts [Tab] to show the list of known images.
Map installer
-------------
- fixed parsing of the root device specification.
- fixed setting of the root device when the boot image doesn't
define it.
- reduced the number of installable images from 19 to 16. (Because the
descriptors have grown.)
Documentation
-------------
- added a booting basics section.
- many minor changes.
Changes from version 1 to 2
---------------------------
Boot sector
-----------
- added command-line editing.
- added debugging support (-DDEBUG).
- added support for compacted maps.
- some cosmetic changes.
Map installer
-------------
- major rewrite.
- files that contain "holes" are now handled properly.
- added map compaction.
- devices are now created on the fly only if they can't be found in /dev.
- improved sanity checking.
- can now boot other operating systems.
- can now boot unstripped kernel executables.
- added support for a disk parameter file.
- reduced the number of installable images from 21 to 19.
- changed the command-line syntax.
- root and boot can now be specified on the command line.
Documentation
-------------
- many changes, including correction of some minor errors.
Changes from version 0 to 1
---------------------------
Boot sector
-----------
- tested as master boot record.
- improved the boot prompt invocation method.
- increased the number of installable images to 21.
- added a help facility.
- improved read error handling and error reporting in the boot loader.
- added a second stage boot loader.
Map installer
-------------
- fixed some minor bugs in the map installer. Removed all compiler
warnings.
- added labeling of images.
- added version checking for the boot sector.
- replaced option -r by -m. -r will be available for a while for
compatibility.
- added booting from device files (that have boot images written on them).
- BIOS device codes can now be specified for boot image files too.
- added concatenation of images. (This is a test feature that will be
changed in the future.)
Documentation
-------------
- some minor documentation errors have been corrected.
- the README now warns that the map has to be rebuilt after the images are
replaced or moved.
- added a files, a hints and an examples section.

310
Linux-0.98/sources/sbin/lilo/lilo.6.README Normal file
View File

@@ -0,0 +1,310 @@
LILO - Generic Boot Loader for Linux ("LInux LOader") by Werner Almesberger
=============================================================================
This is an ALPHA test release of a new boot loader. Be sure to have some
means to boot your system from a different media if you install LILO on your
hard disk.
NOTE: Most of the documentation has moved into the LaTeX document doc.tex.
This is only a minimal description for those who can't print or pre-
view LaTeX documents.
Features
--------
- does not depend on the file system. (Tested with Minix, EXT FS and MS-DOS
FS.)
- can be used to boot from floppies and from hard disks.
- can replace the master boot record.
- can boot non-Linux systems (MS-DOS, DR DOS, OS/2, ...) and unstripped
kernels.
- supports up to 16 different boot images that can be selected at boot
time. The root disk/partition can be set independently for each
image.
- boot sector, file map and boot images can be all on different disks or
partitions.
Restrictions and known problems
-------------------------------
- SCSI disks are not fully supported yet. (Still waiting for some kernel
changes.)
- booting other operating systems may not work everywhere. If everything
but booting a non-Linux OS from LILO works on your system, you should
boot LILO by BOOTACTV and select the alternate OS with the latter as a
temporary work-around.
- booting non-Linux systems from the second hard disk ("D:") is not yet
supported.
Files
-----
Files contained in lilo.5.tar.Z:
README This file.
Makefile Makefile for everything else.
*.c, *.h LILO map installer source.
*.S LILO boot loader source.
activate.c Simple boot partition setter.
dparam.s Disk parameter dumper source.
disktab Sample disk parameter table.
Files created after make (among others):
boot.b Combined boot sector.
chain.b Chain loader.
lilo LILO installer.
activate Simple boot partition setter.
dparam.com MS-DOS executable of the disk parameter dumper.
!! STOP READING HERE IF YOU CAN USE THE LaTeX VERSION OF THE DOCUMENTATION !!
The LaTeX part is generally more up to date and contains more useful
hints and examples. The following sections have been trimmed to make
it easier to maintain them, e.g. by removing as many version-dependen-
cies as possible.
Installation
------------
You have to run the 0.96c-pl1 kernel or any newer release.
This section describes one possible installation of LILO. Please read
"Booting basics" in the LaTeX document for the whole story.
Non-SCSI installation:
Step 1: Extract all files from lilo.6.tar.Z, run make to compile and assemble
all parts.
Step 2: Read the "LILO installer" section in this README and be sure to
understand what the command-line options do.
Step 3: Do make install to copy all LILO files to /etc/lilo
Step 4: Install lilo on a floppy disk:
lilo -b /dev/fd0 -i boot.b -v -v -v /your_kernel_image
Step 5: Reboot. If this doesn't work or if you don't want to install LILO on
your hard disk anyway, you can stop here.
Step 6: Get a working bootimage and a rootimage. If you have reason to be
paranoid about your boot sector, mount the rootimage and copy your
current boot sector to a file on it, e.g.
dd if=/dev/hda2 of=/fd/boot_sector bs=512 count=1
Step 7: Create a shell script /etc/lilo/install that installs LILO on your
hard disk, e.g.
# cat >/etc/lilo/install
#!/bin/sh
/etc/lilo/lilo <all_necessary_options> -i /etc/lilo/boot.b $* \
/kernel_image(s)
^D
# chmod 755 /etc/lilo/install
Step 8: Now, you can check what LILO would do if you
were about to install it on your hard disk:
/etc/lilo/install -v -v -v -t
Step 9: If necessary, install a boot partition switcher. Run /etc/lilo/install
to install LILO on your hard disk. If necessary, mark that partition
"active".
Step 10: Reboot.
SCSI installation:
Like non-SCSI installation, but you have to put the parameters of your
SCSI drive into the file /etc/lilo/disktab.
IMPORTANT: You have to repeat the installation procedure whenever any of the
boot images is replaced or moved (e.g. after the kernel is re-
compiled.) The -i option can be omitted if a LILO boot sector has
already been installed.
LILO Installer
--------------
The LILO installer accepts the following command-line options:
-b boot_device
Sets the name of the device that contains the boot sector. If -b is
omitted, the boot sector is read from (and possibly written to) the
device that is currently mounted as root. A BIOS device code can be
specified.
-c
Tries to merge read requests for adjacent sectors into a single read
request. This drastically reduces load time and keeps the map
smaller.
-d tsecs
Specifies the number of tenths of seconds LILO should wait before
booting the first image. This is useful on systems that immediately
boot from the hard disk after enabling the keyboard. LILO doesn't
wait if -d is omitted.
-i boot_sector
Install the specified file as the new boot sector. If -i is omitted,
the old boot sector is modified. A BIOS device code can be specified.
-l
Generate linear sector addresses instead of sector/head/cylinder
addresses. Linear addresses are translated at run time and do not
depend on disk geometry. This is experimental and is not (yet)
intended for common use.
-m map_file
Specifies the location of the map file. If -m is omitted, a file
/etc/lilo/map is used. A BIOS device code can be specified.
-r root_dir
Change the root directory to root_dir before doing anything else.
This is typically used when running off a floppy, with the normal
root mounted at some directory.
-s backup_file
Copy the old boot sector to backup_file instead of
/etc/lilo/boot.<number>
-S backup_file
Like -s, but overwrite an old backup copy if it already exists.
-t
Test only. This performs the entire installation procedure except
replacing the map file and writing the modified boot sector. This
can be used in conjunction with the -v option to verify that LILO
will use sane values.
-v
Turns on lots of progress reporting. Repeating -v will turn on more
reporting. (-v -v -v -v -v is the highest verbosity level and
displays all sector mappings before and after compaction.)
If no image files are specified, the currently mapped files are listed. Only
the options -m and -v can be used in this mode.
If at least one file name is specified, a new map is created for those files
and they are registered in the boot sector. If the root device has been set
in the images, it is copied into the descriptors in the boot sector. If no
root device has been set, the current root device is used. The root device
can be overridden by appending them to the image specification, e.g.
lilo foo,/dev/hda1
^ ^
image root
Either numbers or device names can be used.
It is perfectly valid to use different root settings for the same image,
because LILO stores them in the image descriptors and not in the images
themselves. Example:
lin-hd=/linux,/dev/hda2 \
lin-fd=/linux,/dev/fd0
The image files can reside on any media that is accessible at boot time.
There's no need to put them on the root device, although this certainly
doesn't hurt.
If LILO doesn't guess the correct BIOS device code, it can be specified by
appending a colon and the code to the file name, e.g. /linux:0x80
LILO uses the first file name (without its path) of each image specification
to identify that image. A different name can be specified by prefixing the
specification with label= e.g.
msdos=/etc/lilo/chain.b+/dev/sda1@/dev/sda
LILO can boot the following types of images:
- "classic" boot images from a file
- "classic" boot images from a device
- unstripped kernel executables
- the boot sector of some other operating system
The image type is determined by the syntax that is used for the image
specification.
Booting "classic" boot images from a file
-----------------------------------------
If defined, the root device definition is taken from the boot image.
The image is specified as follows:
file_name [ :BIOS_code ]
I.e. /linux
Booting "classic" boot images from a device
-------------------------------------------
The root device setting in the image is ignored. The range of sectors
that should be mapped, has to be specified. Either a range (start-end)
or a start and a distance (start+number) have to be specified. start
and end ae zero-based. If only the start if specified, only that sector
is mapped.
device_name [ :BIOS_code] #start [ -end | +number ]
I.e. /dev/fd0#1+512
Booting unstripped kernel executables
-------------------------------------
Unstripped kernel executables contain no root device information.
The setup code of the kernel has also to be added to the kernel. First,
it has to be copied to a suitable place and its header has to be removed,
e.g.
(dd of=/dev/null bs=32 count=1; dd) </usr/src/linux/boot/setup \
>/etc/lilo/setup.b
The image specification looks like this:
setup_name [ :BIOS_code ] +kernel_name [ :BIOS_code ]
I.e. /etc/lilo/setup.b+/usr/src/linux/tools/system
Booting a foreign operating system
----------------------------------
LILO can even boot other operating systems, e.g. MS-DOS. This feature
is new and may not yet work totally reliably. (Reported to work with
PC-DOS 4.0, MS-DOS 5.0 and DR-DOS 6.0.) To boot an other operating
system, the name of a loader program, the device that contains the boot
sector and the device that contains the master boot record have to be
specified:
loader+boot_dev [ :BIOS_code ] @ [ part_dev ]
I.e. /etc/lilo/chain.b+/dev/hda2@/dev/hda
The boot sector is merged with the partition table and stored in the map
file.
Currently, only the loader chain.b exists.
LILO may create some device special files in your /tmp directory that are
not removed if an error occurs. They are named /tmp/dev.<number>.
Bugs and such
-------------
Please send all bug reports to almesber@nessie.cs.id.ethz.ch

310
Linux-0.98/sources/sbin/lilo/lilo.6.README.txt Normal file
View File

@@ -0,0 +1,310 @@
LILO - Generic Boot Loader for Linux ("LInux LOader") by Werner Almesberger
=============================================================================
This is an ALPHA test release of a new boot loader. Be sure to have some
means to boot your system from a different media if you install LILO on your
hard disk.
NOTE: Most of the documentation has moved into the LaTeX document doc.tex.
This is only a minimal description for those who can't print or pre-
view LaTeX documents.
Features
--------
- does not depend on the file system. (Tested with Minix, EXT FS and MS-DOS
FS.)
- can be used to boot from floppies and from hard disks.
- can replace the master boot record.
- can boot non-Linux systems (MS-DOS, DR DOS, OS/2, ...) and unstripped
kernels.
- supports up to 16 different boot images that can be selected at boot
time. The root disk/partition can be set independently for each
image.
- boot sector, file map and boot images can be all on different disks or
partitions.
Restrictions and known problems
-------------------------------
- SCSI disks are not fully supported yet. (Still waiting for some kernel
changes.)
- booting other operating systems may not work everywhere. If everything
but booting a non-Linux OS from LILO works on your system, you should
boot LILO by BOOTACTV and select the alternate OS with the latter as a
temporary work-around.
- booting non-Linux systems from the second hard disk ("D:") is not yet
supported.
Files
-----
Files contained in lilo.5.tar.Z:
README This file.
Makefile Makefile for everything else.
*.c, *.h LILO map installer source.
*.S LILO boot loader source.
activate.c Simple boot partition setter.
dparam.s Disk parameter dumper source.
disktab Sample disk parameter table.
Files created after make (among others):
boot.b Combined boot sector.
chain.b Chain loader.
lilo LILO installer.
activate Simple boot partition setter.
dparam.com MS-DOS executable of the disk parameter dumper.
!! STOP READING HERE IF YOU CAN USE THE LaTeX VERSION OF THE DOCUMENTATION !!
The LaTeX part is generally more up to date and contains more useful
hints and examples. The following sections have been trimmed to make
it easier to maintain them, e.g. by removing as many version-dependen-
cies as possible.
Installation
------------
You have to run the 0.96c-pl1 kernel or any newer release.
This section describes one possible installation of LILO. Please read
"Booting basics" in the LaTeX document for the whole story.
Non-SCSI installation:
Step 1: Extract all files from lilo.6.tar.Z, run make to compile and assemble
all parts.
Step 2: Read the "LILO installer" section in this README and be sure to
understand what the command-line options do.
Step 3: Do make install to copy all LILO files to /etc/lilo
Step 4: Install lilo on a floppy disk:
lilo -b /dev/fd0 -i boot.b -v -v -v /your_kernel_image
Step 5: Reboot. If this doesn't work or if you don't want to install LILO on
your hard disk anyway, you can stop here.
Step 6: Get a working bootimage and a rootimage. If you have reason to be
paranoid about your boot sector, mount the rootimage and copy your
current boot sector to a file on it, e.g.
dd if=/dev/hda2 of=/fd/boot_sector bs=512 count=1
Step 7: Create a shell script /etc/lilo/install that installs LILO on your
hard disk, e.g.
# cat >/etc/lilo/install
#!/bin/sh
/etc/lilo/lilo <all_necessary_options> -i /etc/lilo/boot.b $* \
/kernel_image(s)
^D
# chmod 755 /etc/lilo/install
Step 8: Now, you can check what LILO would do if you
were about to install it on your hard disk:
/etc/lilo/install -v -v -v -t
Step 9: If necessary, install a boot partition switcher. Run /etc/lilo/install
to install LILO on your hard disk. If necessary, mark that partition
"active".
Step 10: Reboot.
SCSI installation:
Like non-SCSI installation, but you have to put the parameters of your
SCSI drive into the file /etc/lilo/disktab.
IMPORTANT: You have to repeat the installation procedure whenever any of the
boot images is replaced or moved (e.g. after the kernel is re-
compiled.) The -i option can be omitted if a LILO boot sector has
already been installed.
LILO Installer
--------------
The LILO installer accepts the following command-line options:
-b boot_device
Sets the name of the device that contains the boot sector. If -b is
omitted, the boot sector is read from (and possibly written to) the
device that is currently mounted as root. A BIOS device code can be
specified.
-c
Tries to merge read requests for adjacent sectors into a single read
request. This drastically reduces load time and keeps the map
smaller.
-d tsecs
Specifies the number of tenths of seconds LILO should wait before
booting the first image. This is useful on systems that immediately
boot from the hard disk after enabling the keyboard. LILO doesn't
wait if -d is omitted.
-i boot_sector
Install the specified file as the new boot sector. If -i is omitted,
the old boot sector is modified. A BIOS device code can be specified.
-l
Generate linear sector addresses instead of sector/head/cylinder
addresses. Linear addresses are translated at run time and do not
depend on disk geometry. This is experimental and is not (yet)
intended for common use.
-m map_file
Specifies the location of the map file. If -m is omitted, a file
/etc/lilo/map is used. A BIOS device code can be specified.
-r root_dir
Change the root directory to root_dir before doing anything else.
This is typically used when running off a floppy, with the normal
root mounted at some directory.
-s backup_file
Copy the old boot sector to backup_file instead of
/etc/lilo/boot.<number>
-S backup_file
Like -s, but overwrite an old backup copy if it already exists.
-t
Test only. This performs the entire installation procedure except
replacing the map file and writing the modified boot sector. This
can be used in conjunction with the -v option to verify that LILO
will use sane values.
-v
Turns on lots of progress reporting. Repeating -v will turn on more
reporting. (-v -v -v -v -v is the highest verbosity level and
displays all sector mappings before and after compaction.)
If no image files are specified, the currently mapped files are listed. Only
the options -m and -v can be used in this mode.
If at least one file name is specified, a new map is created for those files
and they are registered in the boot sector. If the root device has been set
in the images, it is copied into the descriptors in the boot sector. If no
root device has been set, the current root device is used. The root device
can be overridden by appending them to the image specification, e.g.
lilo foo,/dev/hda1
^ ^
image root
Either numbers or device names can be used.
It is perfectly valid to use different root settings for the same image,
because LILO stores them in the image descriptors and not in the images
themselves. Example:
lin-hd=/linux,/dev/hda2 \
lin-fd=/linux,/dev/fd0
The image files can reside on any media that is accessible at boot time.
There's no need to put them on the root device, although this certainly
doesn't hurt.
If LILO doesn't guess the correct BIOS device code, it can be specified by
appending a colon and the code to the file name, e.g. /linux:0x80
LILO uses the first file name (without its path) of each image specification
to identify that image. A different name can be specified by prefixing the
specification with label= e.g.
msdos=/etc/lilo/chain.b+/dev/sda1@/dev/sda
LILO can boot the following types of images:
- "classic" boot images from a file
- "classic" boot images from a device
- unstripped kernel executables
- the boot sector of some other operating system
The image type is determined by the syntax that is used for the image
specification.
Booting "classic" boot images from a file
-----------------------------------------
If defined, the root device definition is taken from the boot image.
The image is specified as follows:
file_name [ :BIOS_code ]
I.e. /linux
Booting "classic" boot images from a device
-------------------------------------------
The root device setting in the image is ignored. The range of sectors
that should be mapped, has to be specified. Either a range (start-end)
or a start and a distance (start+number) have to be specified. start
and end ae zero-based. If only the start if specified, only that sector
is mapped.
device_name [ :BIOS_code] #start [ -end | +number ]
I.e. /dev/fd0#1+512
Booting unstripped kernel executables
-------------------------------------
Unstripped kernel executables contain no root device information.
The setup code of the kernel has also to be added to the kernel. First,
it has to be copied to a suitable place and its header has to be removed,
e.g.
(dd of=/dev/null bs=32 count=1; dd) </usr/src/linux/boot/setup \
>/etc/lilo/setup.b
The image specification looks like this:
setup_name [ :BIOS_code ] +kernel_name [ :BIOS_code ]
I.e. /etc/lilo/setup.b+/usr/src/linux/tools/system
Booting a foreign operating system
----------------------------------
LILO can even boot other operating systems, e.g. MS-DOS. This feature
is new and may not yet work totally reliably. (Reported to work with
PC-DOS 4.0, MS-DOS 5.0 and DR-DOS 6.0.) To boot an other operating
system, the name of a loader program, the device that contains the boot
sector and the device that contains the master boot record have to be
specified:
loader+boot_dev [ :BIOS_code ] @ [ part_dev ]
I.e. /etc/lilo/chain.b+/dev/hda2@/dev/hda
The boot sector is merged with the partition table and stored in the map
file.
Currently, only the loader chain.b exists.
LILO may create some device special files in your /tmp directory that are
not removed if an error occurs. They are named /tmp/dev.<number>.
Bugs and such
-------------
Please send all bug reports to almesber@nessie.cs.id.ethz.ch

507
Linux-0.98/sources/sbin/ps-0.98.diff Normal file
View File

@@ -0,0 +1,507 @@
diff -c +recursive orig/ps-0.98/ps.c ps-0.98/ps.c
*** orig/ps-0.98/ps.c Tue Oct 20 13:38:26 1992
--- ps-0.98/ps.c Wed Nov 4 20:44:49 1992
***************
*** 178,184 ****
show_procs()
{
struct task_struct *taskp;
! union task_union task_buf;
int tty, i, uid;
off_t _task = k_addr("_task");
--- 178,185 ----
show_procs()
{
struct task_struct *taskp;
! struct task_struct task_buf;
! char stack_buf[PAGE_SIZE];
int tty, i, uid;
off_t _task = k_addr("_task");
***************
*** 192,218 ****
if (taskp) {
kmemread(&task_buf, taskp, sizeof(task_buf));
/* check if valid, proc may have exited */
! if ((unsigned) task_buf.task.state > 4 ||
! task_buf.task.pid <= 0 && i != 0)
continue;
if (pid >= 0) {
! if (task_buf.task.pid != pid)
continue;
} else if (ctty) {
! if (task_buf.task.tty != tty)
continue;
} else
! if (!all && task_buf.task.uid != uid ||
! !no_ctty && task_buf.task.tty == -1 ||
! run_only && task_buf.task.state != TASK_RUNNING &&
! task_buf.task.state != TASK_UNINTERRUPTIBLE)
continue;
! (fmt_fnc[fmt])(&task_buf);
if (fmt != PS_V && fmt != PS_M)
! show_time(&task_buf);
! printf("%s\n", cmd_args(&task_buf));
}
}
}
--- 193,221 ----
if (taskp) {
kmemread(&task_buf, taskp, sizeof(task_buf));
/* check if valid, proc may have exited */
! if ((unsigned) task_buf.state > 4 ||
! (task_buf.pid <= 0 && i != 0) ||
! !task_buf.kernel_stack_page)
continue;
if (pid >= 0) {
! if (task_buf.pid != pid)
continue;
} else if (ctty) {
! if (task_buf.tty != tty)
continue;
} else
! if (!all && task_buf.uid != uid ||
! !no_ctty && task_buf.tty == -1 ||
! run_only && task_buf.state != TASK_RUNNING &&
! task_buf.state != TASK_UNINTERRUPTIBLE)
continue;
! kmemread(&stack_buf, task_buf.kernel_stack_page, PAGE_SIZE);
! (fmt_fnc[fmt])(&task_buf,&stack_buf);
if (fmt != PS_V && fmt != PS_M)
! show_time(&task_buf, &stack_buf);
! printf("%s\n", cmd_args(&task_buf, &stack_buf));
}
}
}
***************
*** 219,226 ****
! show_short(task)
struct task_struct *task;
{
printf("%5d %s %s",
task->pid,
--- 222,230 ----
! show_short(task, stack)
struct task_struct *task;
+ reg_t * stack;
{
printf("%5d %s %s",
task->pid,
***************
*** 228,235 ****
status(task));
}
! show_long(task)
struct task_struct *task;
{
long ppid;
--- 232,240 ----
status(task));
}
! show_long(task, stack)
struct task_struct *task;
+ reg_t * stack;
{
long ppid;
***************
*** 242,259 ****
ppid,
2 * PZERO - task->counter, /* sort of priority */
PZERO - task->priority, /* nice value */
! VSIZE(task),
task->rss * 4,
(task->state == TASK_INTERRUPTIBLE ||
task->state == TASK_UNINTERRUPTIBLE ||
Debug > 1 && task->state == TASK_STOPPED ?
! wchan(task->tss.ebp, task) : ""),
status(task),
dev_to_tty(task->tty));
}
! show_jobs(task)
struct task_struct *task;
{
long ppid, tpgid;
struct tty_struct *tt;
--- 247,265 ----
ppid,
2 * PZERO - task->counter, /* sort of priority */
PZERO - task->priority, /* nice value */
! VSIZE(task,stack),
task->rss * 4,
(task->state == TASK_INTERRUPTIBLE ||
task->state == TASK_UNINTERRUPTIBLE ||
Debug > 1 && task->state == TASK_STOPPED ?
! wchan(task->tss.ebp, stack) : ""),
status(task),
dev_to_tty(task->tty));
}
! show_jobs(task, stack)
struct task_struct *task;
+ reg_t * stack;
{
long ppid, tpgid;
struct tty_struct *tt;
***************
*** 284,291 ****
task->euid);
}
! show_user(task)
struct task_struct *task;
{
time_t start;
int pcpu, pmem;
--- 290,298 ----
task->euid);
}
! show_user(task, stack)
struct task_struct *task;
+ reg_t * stack;
{
time_t start;
int pcpu, pmem;
***************
*** 309,315 ****
task->pid,
pcpu / 10, pcpu % 10,
pmem / 10, pmem % 10,
! VSIZE(task),
task->rss * 4,
dev_to_tty(task->tty),
status(task),
--- 316,322 ----
task->pid,
pcpu / 10, pcpu % 10,
pmem / 10, pmem % 10,
! VSIZE(task,stack),
task->rss * 4,
dev_to_tty(task->tty),
status(task),
***************
*** 316,323 ****
ctime(&start) + (time_now - start > 3600*24 ? 4 : 10));
}
! show_sig(task)
struct task_struct *task;
{
unsigned long sigignore=0, sigcatch=0, bit=1;
int i;
--- 323,331 ----
ctime(&start) + (time_now - start > 3600*24 ? 4 : 10));
}
! show_sig(task, stack)
struct task_struct *task;
+ reg_t * stack;
{
unsigned long sigignore=0, sigcatch=0, bit=1;
int i;
***************
*** 341,348 ****
dev_to_tty(task->tty));
}
! show_vm(task)
struct task_struct *task;
{
int pmem;
--- 349,357 ----
dev_to_tty(task->tty));
}
! show_vm(task, stack)
struct task_struct *task;
+ reg_t * stack;
{
int pmem;
***************
*** 354,360 ****
printf(" %6d %4d %4d %4d ",
task->maj_flt + (Sum ? task->cmaj_flt : 0),
task->end_code / 1024,
! SIZE(task), task->rss*4);
if (task->rlim[RLIMIT_RSS].rlim_cur == RLIM_INFINITY)
printf(" xx ");
else
--- 363,369 ----
printf(" %6d %4d %4d %4d ",
task->maj_flt + (Sum ? task->cmaj_flt : 0),
task->end_code / 1024,
! SIZE(task, stack), task->rss*4);
if (task->rlim[RLIMIT_RSS].rlim_cur == RLIM_INFINITY)
printf(" xx ");
else
***************
*** 364,371 ****
}
! show_m(task)
struct task_struct *task;
{
int i;
unsigned long pagedir[0x300];
--- 373,381 ----
}
! show_m(task, stack)
struct task_struct *task;
+ reg_t * stack;
{
int i;
unsigned long pagedir[0x300];
***************
*** 431,438 ****
dt << pg_shift);
}
! show_regs(task)
struct task_struct *task;
{
printf("%2d %5d %8x %8x %8x ",
task->start_code >> 26,
--- 441,449 ----
dt << pg_shift);
}
! show_regs(task, stack)
struct task_struct *task;
+ reg_t * stack;
{
printf("%2d %5d %8x %8x %8x ",
task->start_code >> 26,
***************
*** 441,448 ****
task->start_code >> 16,
**/
task->start_stack,
! KSTK_ESP(task),
! KSTK_EIP(task));
prtime(task->timeout, jiffies);
prtime(task->it_real_value, 0);
--- 452,459 ----
task->start_code >> 16,
**/
task->start_stack,
! KSTK_ESP(stack),
! KSTK_EIP(stack));
prtime(task->timeout, jiffies);
prtime(task->it_real_value, 0);
***************
*** 487,494 ****
};
! show_time(task)
struct task_struct *task;
{
unsigned t;
--- 498,506 ----
};
! show_time(task, stack)
struct task_struct *task;
+ reg_t * stack;
{
unsigned t;
***************
*** 500,507 ****
}
char *
! status(task)
struct task_struct *task;
{
static char buf[5] = " ";
--- 512,520 ----
}
char *
! status(task, stack)
struct task_struct *task;
+ reg_t * stack;
{
static char buf[5] = " ";
diff -c +recursive orig/ps-0.98/ps.h ps-0.98/ps.h
*** orig/ps-0.98/ps.h Tue Sep 22 22:06:56 1992
--- ps-0.98/ps.h Wed Nov 4 20:44:49 1992
***************
*** 21,42 ****
#define PAGE_MASK 0xfff
! #define KSTK_EIP(task) (*((unsigned long *)(task)+1019))
! #define KSTK_ESP(task) (*((unsigned long *)(task)+1022))
! #define _SSIZE(task) (TASK_SIZE - KSTK_ESP(task))
! #define SSIZE(task) (KSTK_ESP(task) ? _SSIZE(task) : 0)
! #define VSIZE(task) (((task)->brk + 1023 + SSIZE(task)) / 1024)
! #define SIZE(task) (((task)->brk - (task)->end_code + 1023 + \
! SSIZE(task)) / 1024)
! typedef unsigned reg_t;
!
! union task_union {
! struct task_struct task;
! reg_t stack[PAGE_SIZE/4];
! };
char *find_func();
unsigned long k_addr();
--- 21,37 ----
#define PAGE_MASK 0xfff
! #define KSTK_EIP(stack) ((stack)[1019])
! #define KSTK_ESP(stack) ((stack)[1022])
! #define _SSIZE(stack) (TASK_SIZE - KSTK_ESP(stack))
! #define SSIZE(stack) (KSTK_ESP(stack) ? _SSIZE(stack) : 0)
! #define VSIZE(task,stack) (((task)->brk + 1023 + SSIZE(stack)) / 1024)
! #define SIZE(task,stack) (((task)->brk - (task)->end_code + 1023 + \
! SSIZE(stack)) / 1024)
+ typedef unsigned reg_t;
char *find_func();
unsigned long k_addr();
diff -c +recursive orig/ps-0.98/top.c ps-0.98/top.c
*** orig/ps-0.98/top.c Fri Oct 16 19:55:57 1992
--- ps-0.98/top.c Thu Nov 5 22:04:24 1992
***************
*** 54,60 ****
char hdr[200];
char *title="TOP by Roger Binns Ps (c) 1992 Branko Lankester";
! void do_it(struct task_struct *task, int num);
void do_key(char c);
char *cm, *clrtobot, *cl, *so, *se, *clrtoeol, *mb, *md, *us, *ue;
char *outp;
--- 54,60 ----
char hdr[200];
char *title="TOP by Roger Binns Ps (c) 1992 Branko Lankester";
! void do_it(struct task_struct *task, reg_t *stack, int num);
void do_key(char c);
char *cm, *clrtobot, *cl, *so, *se, *clrtoeol, *mb, *md, *us, *ue;
char *outp;
***************
*** 424,430 ****
show_procs()
{
struct task_struct *taskp;
! union task_union task_buf;
int tty, i, uid;
off_t _task = k_addr("_task");
--- 424,431 ----
show_procs()
{
struct task_struct *taskp;
! struct task_struct task_buf;
! char stack_buf[PAGE_SIZE];
int tty, i, uid;
off_t _task = k_addr("_task");
***************
*** 436,450 ****
if (taskp) {
kmemread(&task_buf, taskp, sizeof(task_buf));
/* check if valid, proc may have exited */
! if ((unsigned) task_buf.task.state > 4 ||
! task_buf.task.pid <= 0 && i != 0)
continue;
! do_it((struct task_struct *)&task_buf, i);
}
}
}
! void do_it(struct task_struct *task, int num)
{
unsigned t, i;
time_t now, start;
--- 437,453 ----
if (taskp) {
kmemread(&task_buf, taskp, sizeof(task_buf));
/* check if valid, proc may have exited */
! if ((unsigned) task_buf.state > 4 ||
! task_buf.pid <= 0 && i != 0 ||
! !task_buf.kernel_stack_page)
continue;
! kmemread(&stack_buf, task_buf.kernel_stack_page, PAGE_SIZE);
! do_it(&task_buf, (reg_t *) &stack_buf, i);
}
}
}
! void do_it(struct task_struct *task, reg_t *stack, int num)
{
unsigned t, i;
time_t now, start;
***************
*** 495,502 ****
case P_NICE: sprintf(tmp, "%3d ", PZERO-task->priority); break;
case P_PAGEIN: sprintf(tmp, "%6d ", task->maj_flt+(Sum ? task->cmaj_flt : 0)); break;
case P_TSIZ: sprintf(tmp, "%5d ", task->end_code/1024); break;
! case P_DSIZ: sprintf(tmp, "%5d ", SIZE(task)); break;
! case P_SIZE: sprintf(tmp, "%5d ", VSIZE(task)); break;
case P_TRS: sprintf(tmp, "%4d ", TRS); break;
case P_SWAP: sprintf(tmp, "%4d ", SWAP); break;
case P_SHARE: sprintf(tmp, "%5d ", SHARE); break;
--- 498,505 ----
case P_NICE: sprintf(tmp, "%3d ", PZERO-task->priority); break;
case P_PAGEIN: sprintf(tmp, "%6d ", task->maj_flt+(Sum ? task->cmaj_flt : 0)); break;
case P_TSIZ: sprintf(tmp, "%5d ", task->end_code/1024); break;
! case P_DSIZ: sprintf(tmp, "%5d ", SIZE(task,stack)); break;
! case P_SIZE: sprintf(tmp, "%5d ", VSIZE(task,stack)); break;
case P_TRS: sprintf(tmp, "%4d ", TRS); break;
case P_SWAP: sprintf(tmp, "%4d ", SWAP); break;
case P_SHARE: sprintf(tmp, "%5d ", SHARE); break;
***************
*** 507,513 ****
case P_WCHAN: sprintf(tmp, "%-9.9s ",
(task->state == TASK_INTERRUPTIBLE ||
task->state == TASK_UNINTERRUPTIBLE ?
! wchan(task->tss.ebp, task) : "")); break;
case P_STAT: sprintf(tmp, "%-4.4s ", status(task)); break;
case P_TIME: sprintf(tmp, "%3d:%02d ", t/60, t%60); break;
case P_COMMAND: strcpy(tmp, cmd_args(task)); break;
--- 510,516 ----
case P_WCHAN: sprintf(tmp, "%-9.9s ",
(task->state == TASK_INTERRUPTIBLE ||
task->state == TASK_UNINTERRUPTIBLE ?
! wchan(task->tss.ebp, stack) : "")); break;
case P_STAT: sprintf(tmp, "%-4.4s ", status(task)); break;
case P_TIME: sprintf(tmp, "%3d:%02d ", t/60, t%60); break;
case P_COMMAND: strcpy(tmp, cmd_args(task)); break;

66
Linux-0.98/sources/sbin/strace.README Normal file
View File

@@ -0,0 +1,66 @@
/*
* @(#)README 1.4 91/09/06
*
* Copyright (C) 1991 Paul Kranenburg.
*
* Please send comments, enhancements or any other useful ideas to
* the address at the end of this file.
*
*/
strace(1) is a system call tracer for Sun(tm) systems much like the
Sun supplied program trace(1). strace(1) is a useful utility to sort
of debug programs for which no source is available which unfortunately
includes almost all of the Sun supplied system software.
Like trace(1), strace displays each system call and its arguments as it
is invoked by the traced process, but tries to do a better job of
decoding the arguments, displaying them in symbolic format whenever
possible. Passed structures/character arrays are read from the process'
address space and displayed in an appropriate format.
It is also possible to instruct strace to trace child processes as
they are created by the fork(2) system call. However, this is slightly
involved for two reasons: 1) the trace flag is cleared in the child
process by the fork system call, so we must make a special effort to
gain control of the child (see NOTES below), 2) our tracing manipulations
of the child may interfere with a possible wait(2) system call executed
by the (also traced) parent process. In this case we don't allow the parent
to continue until one of its children enters a state that may cause the
parent's wait(2) call to return.
NOTES.
o Not all system calls have been implemented yet as described
above (see dummy.h for a list), these calls only have their args
displayed as hex numbers.
o The program draws heavily on Sun's extensions to the ptrace(2)
system call.
o This release is based upon SunOS 4.1.1. The syscall list (syscall.h)
and ioctl's (ioctlent.h) are probably most critically dependant
on the OS version (see also /sys/os/init_sysent.c).
o The way in which child processes are caught and attached to after
the fork() call is Sparc-specific (in fact it has the looks of a
terrible hack). Also, this trick won't work with vfork(2).
Enhancements are sollicited for.
INSTALLATION.
Edit the paths in the Makefile to suit your local system.
Enter the usual make commands (`make debug' to enable the
compiler `-g' flag).
COMMENTS TO:
P. Kranenburg
Department of Computer Science
Erasmus University Rotterdam
P.O. Box 1738
NL-3000 DR Rotterdam
e-mail: pk@cs.few.eur.nl

1053
Linux-0.98/sources/sbin/syslogd.c Normal file
View File

File diff suppressed because it is too large Load Diff

BIN
Linux-0.98/sources/sbin/syslogs.c.Z.uue Normal file
View File

Binary file not shown.

BIN
Linux-0.98/sources/sbin/sysvboot.taz Normal file
View File

Binary file not shown.