system/freebsd-src
system/freebsd-src
1
0
Fork 0
mirror of https://github.com/freebsd/freebsd-src synced 2024-09-20 08:44:33 +00:00
Code Issues Packages Projects Releases Wiki Activity

Added more missing manual pages from 1.1.5.

Browse source
This commit is contained in:
David Greenman 1995-01-25 09:18:56 +00:00
parent 798bb3d232
commit db35f309d1
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/head/; revision=5884
11 changed files with 1947 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
share/man/man4/Makefile
View file

@ -1,8 +1,9 @@
# @(#)Makefile 8.1 (Berkeley) 6/18/93
MAN4= apm.4 bpf.4 clnp.4 cltp.4 drum.4 esis.4 fd.4 icmp.4 idp.4 inet.4 ip.4 \
iso.4 lkm.4 lo.4 netintro.4 ns.4 nsip.4 null.4 pty.4 route.4 \
spp.4 tcp.4 termios.4 tp.4 tty.4 udp.4 unix.4 yp.4
MAN4= apm.4 bpf.4 cd.4 ch.4 clnp.4 cltp.4 ddb.4 drum.4 esis.4 fd.4 \
icmp.4 idp.4 inet.4 ip.4 iso.4 lkm.4 lo.4 netintro.4 ns.4 nsip.4 \
null.4 pty.4 route.4 scsi.4 sd.4 spp.4 st.4 su.4 tcp.4 termios.4 \
tp.4 tty.4 udp.4 uk.4 unix.4 yp.4
MLINKS+=fd.4 stderr.4 fd.4 stdin.4 fd.4 stdout.4
MLINKS+=netintro.4 networking.4
# XXX NOT IMPORTED: man4.hp300 man4.sparc man4.tahoe man4.vax

179
share/man/man4/cd.4 Normal file
View file

@ -0,0 +1,179 @@
.Dd August 27, 1993
.Dt CD 4
.Os FreeBSD
.Sh NAME
.Nm cd
.Nd scsi cdrom driver
.Sh SYNOPSIS
.Nm device-driver cd
.Op Ar count
.Sh DESCRIPTION
The
.Xr cd
driver provides support for a
.Em scsi
cdrom. It allows the cdrom
to be divided up into a set of pseudo devices called
.Em partitions.
In an attempt to look like regular disks the
.Nm
driver synthesises a partition table, with one partition covering the entire
cdrom. A user might (for some amazing reason) add another partition to the
cdrom by using disklabel, but it will last only until the cdrom is unmounted.
A Partition can have both a
.Em raw
interface
and a
.Em Block mode
interface.
In general the interfaces are similar to those described by
.Xr wd 4
or
.Xr sd 4 .
.Pp
Where the
.Xr wd 4
device has a fairly low level interface to the system,
.Em SCSI
devices have a much higher level interface and talk to the system via
a
.Em SCSI Adapter
and a
.Em Scsi Adapter driver
e.g.
.Xr AHA1542 .
A scsi adapter must also be separatly configured into the system
before a scsi cdrom can be configured.
.Pp
As the scsi adapter is probed during boot, the
.Em SCSI
bus is scanned for devices. Any devices found which answer as 'Readonly'
type devices will be 'attached' to the
.Nm
driver. The first found will be attached as
.Em cd0
and the next,
.Em cd1
etc.
.Pp
The system utility
.Xr disklabel 1
may be used to read the synthesized
.Xr disklabel 5
structure, which will contain correct figures for the size of the cdrom
should that information be required.
.Pp
.Sh KERNEL CONFIGURATION
Any number of cdroms may be attached to the system regardless of system
configuration as all resources are dynamically allocated.
.Pp
.Sh IOCTLS
The following
.Xr ioctl 2
calls apply to scsi cdroms
in the header files
.Em sys/cdio.h.
and
.Em sys/disklabel.h
.Bl -tag -width CDIOCPLAYAUDIO____
.It Dv DIOCGDINFO
Read, from the kernel, the in-core copy of the disklabel for the
drive. This will be a ficticious disklabel it will contain information
read from the scsi inquiry commands, and should be the same as
the information printed at boot.
.It Dv DIOCSDINFO
Give the driver a new disklabel to use. The driver will NOT try write the new
disklabel to the disk. (ok?)
.It CDIOCPLAYTRACKS
Start Audio playback given a track address and length.
.It CDIOCPLAYBLOCKS
Start Audio playback given a block address and length.
.It CDIOCPLAYMSF
Start Audio playback given a 'Minutes/ seconds/ frames' address and length.
.It CDIOCREADSUBCHANNEL
Read information from the subchannel at the location specified.
.It CDIOREADTOCHEADER
Return summary information about the table of contents for the mounted cdrom.
.It CDIOREADTOCENTRYS
Return information from the table of contents entries mentionned.
.It CDIOCSETPATCH
Attach various audio channels to various output channels.
.It CDIOCGETVOL
Get information about the volume settings of the output channels.
.It CDIOCSETVOL
Change the volume settings of the output channels.
.It CDIOCSETMONO
Patch all out[put channels to all source channels.
.It CDIOCSETSTERIO
Patch left source channel to the left output channel and the right
source channel to the right output channel.
.It CDIOCSETMUTE
Mute output without changing the volume settings.
.It CDIOCSETLEFT
Attach both output channels to the left source channel.
.It CDIOCSETRIGHT
Attach both output channels to the right source channel.
.It CDIOCSETDEBUG
Turn on debugging for the appropriate device.
.It CDIOCCLRDEBUG
Turn off debugging for the appropriate device.
.It CDIOCPAUSE
Pause audio play, do not reset the location of the read-head.
.It CDIOCRESUME
Resume audio play, Start at the location of the pause.
.It CDIOCRESET
Reset the drive.
.It CDIOCSTART
Tell the drive to spin-up the cdrom.
.It CDIOCSTOP
Tell the drive to spin-down the cdrom.
.It CDIOCEJECT
Eject the cdrom.
.El
.Pp
In addition the general
.Xr scsi 4
ioctls may be used with the
.Nm
driver, if used against the fourth (raw/whole disk) partiton. (e.g. rcd0d)
.Sh NOTES
When a cdrom is changed in a drive controlled by the
.Nm
driver, then the act of changing the media will invalidate the
disklabel and information held within the kernel. To stop corruption,
All accesses to the device will be discarded until there are no more
open file descriptors referencing the device. During this period, all
new open attempts will be rejected. When No more open file descriptors
reference the device, the first next open will load a new set of
figures (including disklabel) for the drive.
The Audio code in the
.Nm
driver only support SCSI2 standard audio commands. As there are many cdrom
manufacturers who have not followed the standard well, there are many
cdroms for which audio will not work. Some work is planned to support
some of the more common 'broken' cdrom drives however this is not yet
under way.
.Sh FILES
.Bl -tag -width /dev/rcd[0-9][a-h] -compact
.It Pa /dev/cd[0-9][a-h]
block mode scsi disks
.It Pa /dev/rcd[0-9][a-h]
raw scsi disks
.El
.Sh DIAGNOSTICS
None.
.Sh SEE ALSO
.Xr disklabel 1
.Xr disklabel 5
.Xr wd 4
.Xr sd 4
.Sh HISTORY
This
.Nm
driver appeared in 386BSD 0.1.

80
share/man/man4/ch.4 Normal file
View file

@ -0,0 +1,80 @@
.Dd August 27, 1993
.Dt CH 4
.Os FreeBSD
.Sh NAME
.Nm ch
.Nd scsi media-changer (juke box) driver
.Sh SYNOPSIS
.Nm device-driver ch
.Op Ar count
.Sh DESCRIPTION
The
.Xr ch
driver provides support for a
.Em scsi
juke box. It allows many slots of media to be multiplexed between a number
of drives.
.Pp
A scsi adapter must also be separatly configured into the system
before a scsi changer can be configured.
.Pp
As the scsi adapter is probed during boot, the
.Em SCSI
bus is scanned for devices. Any devices found which answer as 'Changer'
type devices will be 'attached' to the
.Nm
driver. The first found will be attached as
.Em ch0
and the next,
.Em ch1
etc.
.Pp
.Sh KERNEL CONFIGURATION
In configuring, if an optional
.Ar count
is given in the specification, that number of scsi media changers
are configured; Most storage for them is allocated only when found
so a large number of configured devices is cheap. (once the first
has included the driver).
.Pp
.Sh IOCTLS
The following
.Xr ioctl 2
call applies to the changer. It is defined in
in the header file
.Em sys/chio.h.
.Bl -tag -width DIOCSDINFO
CHIOOP
This appears to be a 'do-everything' call.
.El
.Sh NOTES
The
.Nm
driver was added to the system by
Stefan Grefen (grefen@goofy.zdv.uni-mainz.de)
who apparently had such a device
however It appears as though no-one I have heard of has ever used this
driver. If you use it please let me know so I can test changes.
Stefan appears to have suffered net.death (or at least net.disconnection).
I (julian) have never used this device. If you do please re-write this
man page and send it to me..
.Sh FILES
.Bl -tag -width /dev/ch[0-9] -compact
.It Pa /dev/ch[0-9]
device entries
.El
.Sh DIAGNOSTICS
None.
.Sh SEE ALSO
.Xr sd 4
.Xr st 4
.Xr cd 4
.Sh HISTORY
The
.Nm
driver appeared in 386BSD 0.1

216
share/man/man4/da.4 Normal file
View file

@ -0,0 +1,216 @@
.Dd August 27, 1993
.Dt SD 4
.Os FreeBSD
.Sh NAME
.Nm sd
.Nd scsi disk driver
.Sh SYNOPSIS
.Nm device-driver sd
.Op Ar count
.Sh DESCRIPTION
The
.Xr sd
driver provides support for a
.Em scsi
disk. It allows the disk
to be divided up into a set of pseudo devices called
.Em partitions.
A Partition can have both a
.Em raw
interface
and a
.Em Block mode
interface.
In general the interfaces are similar to those described by
.Xr wd 4
or
.Xr dk 4 .
.Pp
Where the
.Xr wd 4
device has a fairly low level interface to the system,
.Em SCSI
devices have a much higher level interface and talk to the system via
a
.Em SCSI Adapter
and a
.Em Scsi Adapter driver
e.g.
.Xr AHA1542 .
A scsi adapter must also be separatly configured into the system
before a scsi disk can be configured.
.Pp
As the scsi adapter is probed during boot, the
.Em SCSI
bus is scanned for devices. Any devices found which answer as 'Direct'
type devices will be 'attached' to the
.Nm
driver. The first found will be attached as
.Em sd0
and the next,
.Em sd1
etc.
.Pp
.Sh PARTITIONING
The
.Nm
driver allows the disk to have two levels of partitioning.
One which allows it to have
partitions for different Operating systems, (one of which is BSD unix),
(see also for the 386 port,
.Xr fdisk 1
), and within a BSD partition, further partitions which are individually
addressable as separate entries in the
.Em /dev
directory. The second level of partitioning is controlled by the program
.Xr disklabel 1
and is common in format across most BSD operating systems. In most of
the original BSD ports, what is the
BSD part here, is the entire disk, and the outer layer of partitionning
does not exist.
.Nm
will also run in this manner if
.Xr disklabel 1
is run with a blank disk, without first partitioning it
with
.Xr fdisk 1
(or similar).
.Pp
Apologies for the two conflicting usages of the word Partition, but
it's a historical artifact, and the meaning must be judged from context
in each case. The next paragraph will discuss partitions exclusively
in the context of WITHIN a BSD partition on the disk.
.Pp
The first few blocks of the BSD section (maybe all) of the disk contain
some boot code, and a structure, known as the
.Xr disklabel 5
which describes the disk's characteristics and partitioning for BSD.
It is set up by the
.Xr disklabel 1
program, and read in by the kernel when the device is first initialised
during boot. It describes how the drive is further divided. The
.Xr disklabel 5
structure contains room for 8 (usually) partitions. Usually these
partitions are calculated so as to fall evenly on cylinder boundaries,
however on a
.Em SCSI
disk this is sometimes not possible. The reason for doing this is historically
to get better performance, however modern
.Em SCSI
disks often have a variable format, so that it is hard to know at any point
in the disk, where the cylinder or track boundaries are. Added to this, the
fact that
.Em SCSI
disk blocks are addressed soley by their 'block number' and not by
any geometry, leads to the common occurance on
.Em SCSI
disks, of laying out partitions on arbitrary boundaries. Because
modern disks often have large track caches, this often leads to only small
degadations of performance, and is in fact sometimes unavoidable. The
boot messages will suggest a geometry similar in heads and cylinders
to the real geometry, but the disklable need not agree with this for the
system to be able to successfully work with the disk.
.Pp
During booting
with an uninitialised disk, the
.Nm
driver will initialise the 'in-core' copy of the disklabel to the suggested
values, however they are not written to the disk.
.Pp
The fourth partition is special. No matter what the disklabel
says, the fourth partition (partition d) reflectls the entire disk, including
those areas OUTSIDE the BSD partitions. At some times it is suggested that
the c partition might be used to represent the entire BSD partition, so these
two partitions should be avoided when laying out filesystems. The fourth
partition must be used for general
.Xr scsi 4
ioctls.
.Pp
While partitions are only theoretically valid within the BSD partition, they
are specified in terms of absolute block numbers, so it is possible to
specify a partition that lies outside of the BSD partition. This is useful
if one wants to have a /dev entry that points to a partition belonging
to another OS (e.g. DOS).
.Pp
.Sh KERNEL CONFIGURATION
In configuring, if an optional
.Ar count
is given in
the specification, that number of scsi disks are configured;
Most storage for them is allocated only when found so a large number
of configured devices is cheap. (once the first has included the driver).
.Pp
.Sh IOCTLS
The following
.Xr ioctl 2
calls apply to scsi disks as well as to other disks. They are defined
in the header file
.Em disklabel.h.
.Bl -tag -width DIOCSDINFO
.It Dv DIOCSBAD
Usually used to set up a bad-block mapping system on the disk. Scsi
drive incorporate their own bad-block mapping so this is not implimented,
however it MAY be implimented in the future as a 'kludged' interface to the
scsi bad-block mapping.
.It Dv DIOCGDINFO
Read, from the kernel, the in-core copy of the disklabel for the
drive. This may be a ficticious disklabel if the drive has never
been initialised, in which case it will contain information read
from the scsi inquiry commands, and should be the same as
the information printed at boot.
.It Dv DIOCSDINFO
Give the driver a new disklabel to use. The driver will NOT try write the new
disklabel to the disk.
.It Dv DIOCWLABEL
Enable or Disable the driver's software
write protect of the disklabel on the disk.
.It Dv DIOCWDINFO
Give the driver a new disklabel to use. The driver WILL try write the new
disklabel to the disk.
.El
.Pp
In addition, the
.Xr scsi 4
general ioctls may be used with the
.Nm
driver, but only against the fourth (whole disk) partition.
.Sh NOTES
If a removable device is attached to the
.Nm
driver, then the act of changing the media will invalidate the
disklabel and information held within the kernel. To stop corruption,
All accesses to the device will be discarded until there are no more
open file descriptors referencing the device. During this period, all
new open attempts will be rejected. When No more open file descriptors
reference the device, the first next open will load a new set of
figures (including disklabel) for the drive.
An ioctl to map out a bad block is planned. (the code is already present
in the driver).
.Sh FILES
.Bl -tag -width /dev/rsd[0-9][a-h] -compact
.It Pa /dev/sd[0-9][a-h]
block mode scsi disks
.It Pa /dev/rsd[0-9][a-h]
raw scsi disks
.El
.Sh DIAGNOSTICS
None.
.Sh SEE ALSO
.Xr disklabel 1
.Xr disklabel 5
.Xr fdisk 1
.Xr wd 4
.Xr dk 4
(on other systems)
.Sh HISTORY
The
.Nm
driver appeared in MACH 2.5 .

402
share/man/man4/ddb.4 Normal file
View file

@ -0,0 +1,402 @@
.\"
.\" Mach Operating System
.\" Copyright (c) 1991,1990 Carnegie Mellon University
.\" All Rights Reserved.
.\"
.\" Permission to use, copy, modify and distribute this software and its
.\" documentation is hereby granted, provided that both the copyright
.\" notice and this permission notice appear in all copies of the
.\" software, derivative works or modified versions, and any portions
.\" thereof, and that both notices appear in supporting documentation.
.\"
.\" CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS IS"
.\" CONDITION. CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF ANY KIND FOR
.\" ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS SOFTWARE.
.\"
.\" Carnegie Mellon requests users of this software to return to
.\"
.\" Software Distribution Coordinator or Software.Distribution@CS.CMU.EDU
.\" School of Computer Science
.\" Carnegie Mellon University
.\" Pittsburgh PA 15213-3890
.\"
.\" any improvements or extensions that they make and grant Carnegie Mellon
.\" the rights to redistribute these changes.
.\"
.\" changed a \# to #, since groff choked on it.
.\"
.\" HISTORY
.\" ddb.4,v
.\" Revision 1.1 1993/07/15 18:41:02 brezak
.\" Man page for DDB
.\"
.\" Revision 2.6 92/04/08 08:52:57 rpd
.\" Changes from OSF.
.\" [92/01/17 14:19:22 jsb]
.\" Changes for OSF debugger modifications.
.\" [91/12/12 tak]
.\"
.\" Revision 2.5 91/06/25 13:50:22 rpd
.\" Added some watchpoint explanation.
.\" [91/06/25 rpd]
.\"
.\" Revision 2.4 91/06/17 15:47:31 jsb
.\" Added documentation for continue/c, match, search, and watchpoints.
.\" I've not actually explained what a watchpoint is; maybe Rich can
.\" do that (hint, hint).
.\" [91/06/17 10:58:08 jsb]
.\"
.\" Revision 2.3 91/05/14 17:04:23 mrt
.\" Correcting copyright
.\"
.\" Revision 2.2 91/02/14 14:10:06 mrt
.\" Changed to new Mach copyright
.\" [91/02/12 18:10:12 mrt]
.\"
.\" Revision 2.2 90/08/30 14:23:15 dbg
.\" Created.
.\" [90/08/30 dbg]
.\"
.TH ddb 4
.SH NAME
ddb \- kernel debugger
.de XX
.sp
.ti -4n
\\$1
.br
.sp
..
.de XS
.nr )R +\\$1
..
.de XE
.nr )R -\\$1
..
.SH DESCRIPTION
.br
.sp
The kernel debugger has most of the features of the old kdb,
but with a more rational (gdb-like) syntax.
.sp
The current location is called 'dot'. The 'dot' is displayed with
a hexadecimal format at a prompt.
Examine and write commands update 'dot' to the address of the last line
examined or the last location modified, and set 'next' to the address of
the next location to be examined or changed.
Other commands don't change 'dot', and set 'next' to be the same as 'dot'.
.sp
The general command syntax is:
.sp
.ti +4n
\fIcommand[/modifier] address [,count]\fR
.sp
A blank line repeats from the address 'next' with count 1 and no modifiers.
Specifying 'address' sets 'dot' to the address.
Omitting 'address' uses 'dot'.
A missing 'count' is taken to be 1 for printing commands or infinity
for stack traces.
.sp
"\fBddb\fR" has a feature like a command "\fBmore\fR"
for the output. If an output line exceeds the number set in the $lines
variable, it displays "\fI--db_more--\fR"
and waits for a response.
The valid responses for it are:
.XS 4n
.IP \fI\<space>\fR 10n
one more page
.IP \fI\<return>\fR 10n
one more line
.IP \fB\q\fR 10n
abort the current command, and return to the command input mode.
.LP
.sp
.XE 4n
.LP
.B COMMANDS
.sp
.XS 4n
.LP
.XX "\fBexamine(x) \fI[/<modifier>] <addr>[,<count>]\fR"
Display the addressed locations according to the formats in the modifier.
Multiple modifier formats display multiple locations.
If no format is specified, the last formats specified for this command
is used.
.br
The format characters are
.sp
.LP
.XS 2n
.IP b 5n
look at by bytes(8 bits)
.IP h 5n
look at by half words(16 bits)
.IP l 5n
look at by long words(32 bits)
.IP a 5n
print the location being displayed
.IP A 5n
print the location with a line number if possible
.IP x 5n
display in unsigned hex
.IP z 5n
display in signed hex
.IP o 5n
display in unsigned octal
.IP d 5n
display in signed decimal
.IP u 5n
display in unsigned decimal
.IP r 5n
display in current radix, signed
.IP c 5n
display low 8 bits as a character.
Non-printing characters are displayed as an octal escape code (e.g. '\\000').
.IP s 5n
display the null-terminated string at the location.
Non-printing characters are displayed as octal escapes.
.IP m 5n
display in unsigned hex with character dump at the end of each line.
The location is also displayed in hex at the beginning of each line.
.IP i 5n
display as an instruction
.IP I 5n
display as an instruction with possible alternate formats depending on the
machine:
.XE 2n
.LP
.XS 5n
.LP
.IP vax 6n
don't assume that each external label is a procedure entry mask
.IP i386 6n
don't round to the next long word boundary
.IP mips 6n
print register contents
.LP
.XE 5n
.LP
.XX xf
Examine forward.
It executes an examine command with the last specified parameters to it
except that the next address displayed by it is used as the start address.
.XX xb
Examine backward.
It executes an examine command with the last specified parameters to it
except that the last start address subtracted by the size displayed by it
is used as the start address.
.XX "\fBprint[/axzodurc] \fI<addr1> [ <addr2> ... ]\fR"
Print 'addr's according to the modifier character.
Valid formats are: a x z o d u r c.
If no modifier is specified, the last one specified to it is used. 'addr'
can be a string, and it is printed as it is. For example,
.br
.sp
.ti +4n
print/x "eax = " $eax "\\necx = " $ecx "\\n"
.br
.sp
will print like
.sp
.in +4n
eax = xxxxxx
.br
ecx = yyyyyy
.in -4n
.sp
.br
.XX "\fBwrite[/bhl] \fI<addr> <expr1> [ <expr2> ... ]\fR"
Write the expressions at succeeding locations.
The write unit size can be specified in the modifier with a letter
b (byte), h (half word) or l(long word) respectively. If omitted,
long word is assumed.
.br
Warning: since there is no delimiter between expressions, strange
things may happen.
It's best to enclose each expression in parentheses.
.XX "\fBset \fI$<variable> [=] <expr>\fR"
Set the named variable or register with the value of 'expr'.
Valid variable names are described below.
.XX "\fBbreak[/u] \fI<addr>[,<count>]\fR"
Set a break point at 'addr'.
If count is supplied, continues (count-1) times before stopping at the
break point. If the break point is set, a break point number is
printed with '#'. This number can be used in deleting the break point
or adding conditions to it.
.LP
.XS 2n
.IP u 5n
Set a break point in user space address. Without 'u' option,
the address is considered in the kernel space, and wrong space address
is rejected with an error message.
This option can be used only if it is supported by machine dependent
routines.
.LP
.XE 2n
Warning: if a user text is shadowed by a normal user space debugger,
user space break points may not work correctly. Setting a break
point at the low-level code paths may also cause strange behavior.
.XX "\fBdelete \fI<addr>|#<number>\fR"
Delete the break point. The target break point can be specified by a
break point number with '#', or by 'addr' like specified in 'break'
command.
.XX "\fBstep[/p] \fI[,<count>]\fR"
Single step 'count' times.
If 'p' option is specified, print each instruction at each step.
Otherwise, only print the last instruction.
.br
.sp
Warning: depending on machine type, it may not be possible to
single-step through some low-level code paths or user space code.
On machines with software-emulated single-stepping (e.g., pmax),
stepping through code executed by interrupt handlers will probably
do the wrong thing.
.XX "\fBcontinue[/c]\fR"
Continue execution until a breakpoint or watchpoint.
If /c, count instructions while executing.
Some machines (e.g., pmax) also count loads and stores.
.br
.sp
Warning: when counting, the debugger is really silently single-stepping.
This means that single-stepping on low-level code may cause strange
behavior.
.XX "\fBuntil[/p]\fR"
Stop at the next call or return instruction.
If 'p' option is specified, print the call nesting depth and the
cumulative instruction count at each call or return. Otherwise,
only print when the matching return is hit.
.XX "\fBnext[/p]\fR"
Stop at the matching return instruction.
If 'p' option is specified, print the call nesting depth and the
cumulative instruction count at each call or return. Otherwise,
only print when the matching return is hit.
.XX "\fBmatch[/p]\fR"
A synonym for 'next'.
.XX "\fBtrace[/u] \fI[ <frame_addr> ][,<count>]\fR"
Stack trace. 'u' option traces user space; if omitted, only traces
kernel space. 'count' is the number of frames to be traced.
If the 'count' is omitted, all frames are printed.
.br
.sp
Warning: User space stack trace is valid
only if the machine dependent code supports it.
.XX "\fBsearch[/bhl] \fI<addr> <value> [<mask>] [,<count>]\fR"
Search memory for a value. This command might fail in interesting
ways if it doesn't find the searched-for value. This is because
ddb doesn't always recover from touching bad memory. The optional
count argument limits the search.
.XX "\fBshow all procs[/m]\fR"
Display all process information.
This version of "\fBddb\fR"
prints more information than previous one.
It shows process information like "ps".
The process information may not be shown if it is not
supported in the machine, or the bottom of the stack of the
target process is not in the main memory at that time.
The 'm' options will alter the 'ps' display to show vm_map
addresses for the process and not show other info.
.br
.XX "\fBps[/m]\fR"
A synonym for 'show all procs'.
.XX "\fBshow registers\fR"
Display the register set.
If 'u' option is specified, it displays user registers instead of
kernel or currently saved one.
.br
.sp
Warning: The support of 'u' option depends on the machine. If
not supported, incorrect information will be displayed.
.XX "\fBshow map[/f] \fI<addr>\fR"
Prints the vm_map at 'addr'. If the 'f' option is specified the
complete map is printed.
.XX "\fBshow object[/f] \fI<addr>\fR"
Prints the vm_object at 'addr'. If the 'f' option is specified the
complete object is printed.
.XX "\fBshow watches\fR"
Displays all watchpoints.
.XX "\fBwatch \fI<addr>,<size>\fR"
Set a watchpoint for a region. Execution stops
when an attempt to modify the region occurs.
The 'size' argument defaults to 4.
.br
If you specify a wrong space address, the request is rejected
with an error message.
.br
.sp
Warning: Attempts to watch wired kernel memory
may cause unrecoverable error in some systems such as i386.
Watchpoints on user addresses work best.
.br
.LP
.XE 4n
.LP
.sp
.B VARIABLES
.sp
The debugger accesses registers and variables as
.I $<name>.
Register names are as in the "\fBshow registers\fR"
command.
Some variables are suffixed with numbers, and may have some modifier
following a colon immediately after the variable name.
For example, register variables can have 'u' modifier to indicate
user register (e.g. $eax:u).
.br
.sp
Built-in variables currently supported are:
.sp
.IP radix 12n
Input and output radix
.IP maxoff 12n
Addresses are printed as 'symbol'+offset unless offset is greater than maxoff.
.IP maxwidth 12n
The width of the displayed line.
.IP lines 12n
The number of lines. It is used by "more" feature.
.IP tabstops 12n
Tab stop width.
.IP work\fIxx\fR
Work variable.
.I 'xx'
can be 0 to 31.
.LP
.LP
.sp
.B EXPRESSIONS
.sp
Almost all expression operators in C are supported except '~', '^',
and unary '&'.
Special rules in "\fBddb\fR"
are:
.br
.IP "<identifier>" 15n
name of a symbol. It is translated to the address(or value) of it. '.'
and ':' can be used in the identifier. If supported by an object format
dependent routine,
[\fI<file_name>\fR:]\fI<func>\fR[:\fI<line_number>\fR]
[\fI<file_name>\fR:]\fI<variable>\fR, and
\fI<file_name>\fR[:\fI<line_number>\fR]
can be accepted as a symbol.
The symbol may be prefixed with '\fI<symbol_table_name>\fR::'
like 'emulator::mach_msg_trap' to specify other than kernel symbols.
.IP "<number>" 15n
radix is determined by the first two letters:
0x: hex, 0o: octal, 0t: decimal, otherwise, follow current radix.
.IP \. 15n
\'dot'
.IP \+ 15n
\'next'
.IP \.. 15n
address of the start of the last line examined.
Unlike 'dot' or 'next', this is only changed by "examine" or
"write" command.
.IP \' 15n
last address explicitly specified.
.IP "$<variable>" 15n
register name or variable. It is translated to the value of it.
It may be followed by a ':' and modifiers as described above.
.IP # 15n
a binary operator which rounds up the left hand side to the next
multiple of right hand side.
.IP "*<expr>" 15n
indirection. It may be followed by a ':' and modifiers as described above.

308
share/man/man4/sa.4 Normal file
View file

@ -0,0 +1,308 @@
.Dd August 27, 1993
.Dt ST 4
.Os FreeBSD
.Sh NAME
.Nm st
.Nd scsi tape driver
.Sh SYNOPSIS
.Nm device-driver st
.Op Ar count
.Sh DESCRIPTION
The
.Xr st
driver provides support for a
.Em scsi
tape. It allows the tape
to be run in upto four different modes depending on minor numbers
and supports several different 'sub modes'.
The device can have both a
.Em raw
interface
and a
.Em Block mode
interface however only the raw interface is usually used (or recommended).
In general the interfaces are similar to those described by
.Xr wt 4
or
.Xr mt 4 .
.Pp
Where the
.Xr wt 4
device has a fairly low level interface to the system,
.Em SCSI
devices have a much higher level interface and talk to the system via
a
.Em SCSI Adapter
and a
.Em Scsi Adapter driver
e.g.
.Xr AHA1542 .
A scsi adapter must also be separatly configured into the system
before a scsi tape can be configured.
.Pp
As the scsi adapter is probed during boot, the
.Em SCSI
bus is scanned for devices. Any devices found which answer as 'Sequential'
type devices will be attached to the
.Nm
driver. The first found will be attached as
.Em st0
and the next,
.Em st1
etc.
.Pp
.Sh MOUNT SESSIONS
The
.Nm
driver is based around the concept of a
.Em Mount Session
, which is defined as the period between the time that a tape is mounted,
and the time when it is unmounted. Any parameters set during a
.Em Mount Session
remain in effect for the remainder of the session or until replaced. The
Tape can be unmounted, bringing the session to a close in several ways.
These include:
.Bl -tag -width ABOUT_THIS_BIG_BUT_REALLY_BIGGER
.It Pa closing an 'unmount device'
This is referred to as sub-mode 00 (see below). An example is /dev/rst0.
.It Pa an MTOFFL ioctl
Reachable throught the 'offline' command of
.Xr st 1
.It Pa Openning another mode.
Openning a different mode will implicitly unmount the tape, thereby closing
off the mode that was previously mounted. All parameters will be loaded
freshly from the new mode. (see below for more on 'modes').
.El
.Pp
Parameters that are required to last across the unmounting of a tape,
should be set on the control device. This is submode 3 (see below) and is
reached through a file with a name of the form /dev/st{y}ctl.{x}, where
{y} is the drive number and {x} is the mode number.
.Pp
.Sh MODES AND SUB MODES
There are four Operation modes. These are controlled by bits 2
and 3 of the minor number and are designed to allow people to easily
read and write different formats of tape on devices that allow
multiple formats. The parameters for each mode can be set individually
by hand with the
.Xr st 1
variant of the
.Xr mt 1
command. When a device corresponding to a particular mode is first mounted,
The operating parameters for that
.Em Mount Session
Are copied from that mode. Further changes to the parameters during the
session will change those in effect for the session but not those set
in the Operating Mode. To change the parameters for an Operating Mode,
One must either assign the parameters to the control device, or compile
them into the 'Rogues Gallery' table within the driver.
.Pp
In addition to the four Operation Modes mentionned above,
bits 0 and 1 of the minor number are interpretted as being 'sub-modes'.
The following sub-modes are supported
.Bl -tag -width ABOUT_THIS_BIG
.It Pa 00
A close will rewind the device. If the tape has been
written, then a Filemark will be written before the rewind is requested.
The device is UNMOUNTED.
.It Pa 01
A close will leave the tape MOUNTED.
If the tape was written to a filemark will be written.
No other head positioning takes place.
Any further reads or writes will occur directly after the
last read, or the written filemark.
.It Pa 10
A close will rewind the device. If the tape has been
written, then a Filemark will be written before the rewind is requested.
On completion of the rewind an UNLOAD command will be issued.
The device is UNMOUNTED.
.It Pa 11
This is a special mode.
It is known as the
.Em CONTROL DEVICE
for the mode. Parameters set for the mode while in this sub
mode will be remembered from one mount to the next. This allows the
system administrator to set different characteristics (e.g. density,
blocksize, (and eventually compression)) on each mode, and have the
different modes keep those parameters independent of any parameter
changes a user may invoke during a single mount session. At the
completion of the user's mount session, drive parameters will revert
to those set by the administrator. IO operations cannot be performed
on this device/submode. General
.Xr scsi 4
ioctls
.Em MUST
be performed against the control device.
.El
.Sh BLOCKING MODES
Scsi Tapes may run in either 'variable' or 'fixed block' modes.
Most QIC type devices run in Fixed block mode, where most 'reel to reel' tapes and
many new cartridge formats, allow variable blocksize. The difference between
the two is as follows:
.Bl -tag -width variable-blocksize
.It Pa Variable Blocksize
Each write made to the device results in a single logical record
written to the tape. You can never read or write PART of a record
from tape, (though you may request a larger block and read a smaller
record). You cannot read multiple blocks either. Data from a single
write is therefore read by a single read. The block size used may
be any value supported by the device, the scsi adapter and the
system. (often variable between 1 byte and 64k (sometimes more)).
.Pp
When reading a variable record/block from the tape, the head is
logically considered to be immediately after the last item read,
and before the next item after that. If the next item is a Filemark,
but you never read it because you have all the data, then the next
process to read will immediately read the filemark and return EOF.
(assuming you were in non-rewind mode).
.It Pa fixed Blocksize
Data written by the user is passed to the tape as a succession of
fixed size blocks. It may be contiguouse in ram and read in a single
DMA pass, however it is considered to be a series of independent
blocks. You may never write an amount of data that is not an exact
multiple of the blocksize. You may read and write the same data
as a different set of records, In other words, blocks that were
written together may be read separatly, and visa versa.
.Pp
If you ask for more blocks than there are left in the file, then
the drive will encounter the filemark. Because there is some data
to return to you (unless there were no records before the filemark)
the driver will return the data to you (less than you requested),
but hide from you the discovery of the Filemark. The NEXT read
will be returned immediately with an EOF. If you never Make the next
read, but close the device, the next process to read will immediately
read the filemark and return EOF. (assuming you were in non-rewind
mode).
.El
.Sh FILEMARK HANDLING
The handling of filemarks on write is pretty much automatic. If you
have written to the tape, and not done a read since, then a filemark will
be written to the tape when you close the device. If a rewind is requested
after a write, then the driver assumes that you have written the last file
on the tape and ensures that there are two filemarks written to the tape.
It takes into account any filemarks already written (whether by close
or by explicit ioctl). The exception to this is that there seems to be
a standard (which we follow, but don't understand why) that certain
types of tape do not actually write two filemarks to tape,
but when read, report a 'phantom' filemark when the last file is read.
These devices include the QIC family of devices. It might be that this
set of devices is the same set as that of fixed block devices. This has not
been detirmined yet, and they are treated as separate behaviors by the
driver at this time.
.Pp
.SH KERNEL CONFIGURATION
In configuring, if an optional
.Ar count
is given in
the specification, that number of scsi tapes are configured;
Most storage for them is allocated only when found so a large number
of configured devices is cheap. (once the first has included the driver).
.Pp
Because different tape drives behave differently, there is a mechanism
within the source to st, to quickly and conveniently recognise and deal
with brands and models of drive that have special requirements.
.Pp
There is a table (called the rogues gallery) in which the indentification
strings of known errant drives can be stored. Along with each is
a set of flags that allows the setting of densities and blocksizes for each
of the 4 modes, along with a set of 'QUIRK' flags that can be
used to enable or disable sections of code within the driver if a particular
drive is recognised.
.Pp
.Sh IOCTLS
The following
.Xr ioctl 2
calls apply to scsi tapes. Some also apply to other tapes. They are defined
in the header file
.Em /sys/mtio.h.
.Bl -tag -width MTIOCEEOT
.It Pa MTIOCGET
Get the mt control structure filled out by the driver, showing
all the present settings.
.It Pa MTIOCTOP
Perform one of the following operations. These operations all have a
single argument, which is either a boolean, or a signed integer, depending
on the operation.
.Bl -tag -width MTSELDNSTY
.It Pa MTWEOF
Write N end of file marks at the present head position.
.It Pa MTFSF
Skip over N Filemarks. Leave the head on the EOM side of the last skipped
Filemark.
.It Pa MTBSF
Skip BACKWARDS over N Filemarks. Leave the head on the BOM (beginning of media)
side of the last skipped Filemark.
.It Pa MTFSR
Skip forwards over N records.
.It Pa MTBSR
Skip backwards over N records.
.It Pa MTREW
Rewind the device to the beginning of the media.
.It Pa MTOFFL
Rewind the media (and if possible eject). Even if the device cannot
eject the media it will often no longer respond to normal requests.
.It Pa MTNOP
No Op, set status only..
.It Pa MTCACHE
Enable controller Buffering.
.It Pa MTNOCACHE
Disable controller Buffering.
.It Pa MTSETBSIZ
Set the blocksize to use for the device/mode. If the device is capable of
variable blocksize operation, and the blocksize is set to 0, then the drive
will be driven in variable mode. This parameter is in effect for the present
mount session only, unless set on the control device.
.It Pa MTSETDNSTY
Set the Density value (see
.Xr st 1
) to use when running in the mode openned (minor bits 2,3).
This parameter is in effect for the present
mount session only, unless set on the control device.
.El
.It Pa MTIOCIEOT
?Set END of TAPE processing... not yet supported.
.It Pa MTIOCEEOT
?Set END of TAPE processing... not yet supported.
.El
.Pp
In addition, The
.Nm
driver will allow the use of any of the general
.Xr scsi 4
ioctls, as long as the control device is used.
.Sh FILES
.Bl -tag -width /dev/[n][e]rst[0-9].[0-3] -compact
.It Pa /dev/[n][e]rst[0-9].[0-3]
general form:
.It Pa /dev/rst0.0
Mode 0, rewind on close
.It Pa /dev/nrst0.2
Mode 2, No rewind on close
.It Pa /dev/erst0.3
Mode 3, Eject on close (if capable)
.It Pa /dev/rst0
Another name for rst0.0
.It Pa /dev/nrst0
Another name for nrst0.0
.It Pa /dev/st0ctl.0
Parameters set to this device become the default parameters for [en]rst0.0
.It Pa /dev/st0ctl.1
Parameters set to this device become the default parameters for [en]rst0.1
.It Pa /dev/st0ctl.2
Parameters set to this device become the default parameters for [en]rst0.2
.It Pa /dev/st0ctl.3
Parameters set to this device become the default parameters for [en]rst0.3
.El
.Sh DIAGNOSTICS
None.
.Sh SEE ALSO
.Xr mt 1
.Xr st 1
.Sh HISTORY
This
.Nm
driver appeared in MACH 2.5 .

117
share/man/man4/scsi.4 Normal file
View file

@ -0,0 +1,117 @@
.Dd August 27, 1993
.Dt SD 4
.Os FreeBSD
.Sh NAME
.Nm scsi
.Nd scsi system
.Sh SYNOPSIS
.Nm device-driver scbus
.Sh DESCRIPTION
The
.Em scsi
system provides a uniform and modular system for the implimentation
of drivers to control various scsi devices, and to utilise different
scsi adapters through adapter drivers. When the system probes the
.Em SCSI
busses, it attaches any devices it finds to the appropriate
drivers. If no driver seems appropriate, then at attaches the device to the
uk (unknown) driver (if configured), so that user level scsi ioctls may
still be performed against the device.
.Sh KERNEL CONFIGURATION
Continuously changing. check your nearest bsd mailing list.
The option SCSIDEBUG enables the debug ioctl.
.Sh IOCTLS
There are a number of ioctls that will (when the next stage is complete)
work on any
.Em SCSI
device. They are defined in
.Em sys/scsiio.h
and can be applied against any scsi device that allows both read and write,
though for devices such as tape, it must be applied against the control
device. See the manual page for each device type for more information about
how generic scsi ioctls may be applied to a specific device.
.Bl -tag -width DIOCSDINFO____
.It Dv SCIOCRESET*
reset a device.
.It Dv SCIOCDEBUG
Turn on debugging.. All scsi operations originating from this device's driver
will be traced to the console, along with other information. Debugging is
controlled by four bits, described in the header file. If no debugging is
configured into the kernel, debugging will have no effect.
.Em SCSI
debugging is controlled by the configuration option
.Em SCSIDEBUG.
.It Dv SCIOCCOMMAND
Take a scsi command and data from a user process and apply them to the scsi
device. Return all status information and return data to the process. The
ioctl will return a successful status even if the device rejected the
command. As all status is returned to the user, it is up to the user
process to examine this information to decide the success of the command.
.It Dv SCIOCREPROBE
Ask the system to probe the scsi busses for any new devices. If it finds
any, they will be attached to the appropriate drivers. The search can be
narrowed to a specific bus, target or lun. The new device may or may not
be related to the device on which the ioctl was performed.
.It Dv SCIOCIDENTIFY
Ask the driver what it's bus, target and lun are.
.It Dv SCIOCDECONFIG
Ask the device to dissappear. This may not happen if the device is in use.
.El
.Sh NOTES
the generic scsi part of the system is still being mapped out.
Watch this space for changes.
.Pp
A device by the name of su (scsi_user)
(e.g su0-0-0) will map bus, target and lun to minor numbers. I have not
yet decided yet whether this device will be able to open a device that is
already controlled by an explicit driver.
.Sh ADAPTERS
The system allows common device drivers to work through many different
types of adapters. The adapters take requests from the upper layers and do
all IO between the
.Em SCSI
bus and the system. The maximum size of a transfer is governed by the
adapter. Most adapters can transfer 64KB in a single operation, however
many can transfer larger amounts.
.Sh TARGET MODE
Some adapters support
.Em Target mode
in which the system is capable of operating as a device, responding to
operations initioated by another system. Target mode will be supported for
some adapters, but is not yet complete for this version of the scsi system.
.Sh FILES
see other scsi device entries.
.Sh DIAGNOSTICS
When the kernel is compiled with option SCSIDEBUG, the SCIOCDEBUG ioctl
can be used to enable various amounts of tracing information on any
specific device. Devices not being traced will not produce trace information.
The four bits that make up the debug level, each control certain types
of debugging information.
.Bl -tag -width THIS_WIDE_PLEASE
.It Dv Bit 0
Bit 0 shows all scsi bus operations including scsi commands,
error information and the first 48 bytes of any data transferred.
.It Dv Bit 1
Bit 1 shows routines called.
.It Dv Bit 2
Bit 2 shows information about what branches are taken and often some
of the return values of functions.
.It Dv Bit 3
Bit 3 shows more detailed information including DMA scatter-gather logs.
.El
.Sh SEE ALSO
.Xr ch 4
.Xr cd 4
.Xr sd 4
.Xr st 4
.Xr uk 4
.Xr su 4
.Xr aha 4
.Xr ahb 4
.Xr bt 4
.Xr uha 4
.Sh HISTORY
This
.Nm
system appeared in MACH 2.5 at TRW.

216
share/man/man4/sd.4 Normal file
View file

@ -0,0 +1,216 @@
.Dd August 27, 1993
.Dt SD 4
.Os FreeBSD
.Sh NAME
.Nm sd
.Nd scsi disk driver
.Sh SYNOPSIS
.Nm device-driver sd
.Op Ar count
.Sh DESCRIPTION
The
.Xr sd
driver provides support for a
.Em scsi
disk. It allows the disk
to be divided up into a set of pseudo devices called
.Em partitions.
A Partition can have both a
.Em raw
interface
and a
.Em Block mode
interface.
In general the interfaces are similar to those described by
.Xr wd 4
or
.Xr dk 4 .
.Pp
Where the
.Xr wd 4
device has a fairly low level interface to the system,
.Em SCSI
devices have a much higher level interface and talk to the system via
a
.Em SCSI Adapter
and a
.Em Scsi Adapter driver
e.g.
.Xr AHA1542 .
A scsi adapter must also be separatly configured into the system
before a scsi disk can be configured.
.Pp
As the scsi adapter is probed during boot, the
.Em SCSI
bus is scanned for devices. Any devices found which answer as 'Direct'
type devices will be 'attached' to the
.Nm
driver. The first found will be attached as
.Em sd0
and the next,
.Em sd1
etc.
.Pp
.Sh PARTITIONING
The
.Nm
driver allows the disk to have two levels of partitioning.
One which allows it to have
partitions for different Operating systems, (one of which is BSD unix),
(see also for the 386 port,
.Xr fdisk 1
), and within a BSD partition, further partitions which are individually
addressable as separate entries in the
.Em /dev
directory. The second level of partitioning is controlled by the program
.Xr disklabel 1
and is common in format across most BSD operating systems. In most of
the original BSD ports, what is the
BSD part here, is the entire disk, and the outer layer of partitionning
does not exist.
.Nm
will also run in this manner if
.Xr disklabel 1
is run with a blank disk, without first partitioning it
with
.Xr fdisk 1
(or similar).
.Pp
Apologies for the two conflicting usages of the word Partition, but
it's a historical artifact, and the meaning must be judged from context
in each case. The next paragraph will discuss partitions exclusively
in the context of WITHIN a BSD partition on the disk.
.Pp
The first few blocks of the BSD section (maybe all) of the disk contain
some boot code, and a structure, known as the
.Xr disklabel 5
which describes the disk's characteristics and partitioning for BSD.
It is set up by the
.Xr disklabel 1
program, and read in by the kernel when the device is first initialised
during boot. It describes how the drive is further divided. The
.Xr disklabel 5
structure contains room for 8 (usually) partitions. Usually these
partitions are calculated so as to fall evenly on cylinder boundaries,
however on a
.Em SCSI
disk this is sometimes not possible. The reason for doing this is historically
to get better performance, however modern
.Em SCSI
disks often have a variable format, so that it is hard to know at any point
in the disk, where the cylinder or track boundaries are. Added to this, the
fact that
.Em SCSI
disk blocks are addressed soley by their 'block number' and not by
any geometry, leads to the common occurance on
.Em SCSI
disks, of laying out partitions on arbitrary boundaries. Because
modern disks often have large track caches, this often leads to only small
degadations of performance, and is in fact sometimes unavoidable. The
boot messages will suggest a geometry similar in heads and cylinders
to the real geometry, but the disklable need not agree with this for the
system to be able to successfully work with the disk.
.Pp
During booting
with an uninitialised disk, the
.Nm
driver will initialise the 'in-core' copy of the disklabel to the suggested
values, however they are not written to the disk.
.Pp
The fourth partition is special. No matter what the disklabel
says, the fourth partition (partition d) reflectls the entire disk, including
those areas OUTSIDE the BSD partitions. At some times it is suggested that
the c partition might be used to represent the entire BSD partition, so these
two partitions should be avoided when laying out filesystems. The fourth
partition must be used for general
.Xr scsi 4
ioctls.
.Pp
While partitions are only theoretically valid within the BSD partition, they
are specified in terms of absolute block numbers, so it is possible to
specify a partition that lies outside of the BSD partition. This is useful
if one wants to have a /dev entry that points to a partition belonging
to another OS (e.g. DOS).
.Pp
.Sh KERNEL CONFIGURATION
In configuring, if an optional
.Ar count
is given in
the specification, that number of scsi disks are configured;
Most storage for them is allocated only when found so a large number
of configured devices is cheap. (once the first has included the driver).
.Pp
.Sh IOCTLS
The following
.Xr ioctl 2
calls apply to scsi disks as well as to other disks. They are defined
in the header file
.Em disklabel.h.
.Bl -tag -width DIOCSDINFO
.It Dv DIOCSBAD
Usually used to set up a bad-block mapping system on the disk. Scsi
drive incorporate their own bad-block mapping so this is not implimented,
however it MAY be implimented in the future as a 'kludged' interface to the
scsi bad-block mapping.
.It Dv DIOCGDINFO
Read, from the kernel, the in-core copy of the disklabel for the
drive. This may be a ficticious disklabel if the drive has never
been initialised, in which case it will contain information read
from the scsi inquiry commands, and should be the same as
the information printed at boot.
.It Dv DIOCSDINFO
Give the driver a new disklabel to use. The driver will NOT try write the new
disklabel to the disk.
.It Dv DIOCWLABEL
Enable or Disable the driver's software
write protect of the disklabel on the disk.
.It Dv DIOCWDINFO
Give the driver a new disklabel to use. The driver WILL try write the new
disklabel to the disk.
.El
.Pp
In addition, the
.Xr scsi 4
general ioctls may be used with the
.Nm
driver, but only against the fourth (whole disk) partition.
.Sh NOTES
If a removable device is attached to the
.Nm
driver, then the act of changing the media will invalidate the
disklabel and information held within the kernel. To stop corruption,
All accesses to the device will be discarded until there are no more
open file descriptors referencing the device. During this period, all
new open attempts will be rejected. When No more open file descriptors
reference the device, the first next open will load a new set of
figures (including disklabel) for the drive.
An ioctl to map out a bad block is planned. (the code is already present
in the driver).
.Sh FILES
.Bl -tag -width /dev/rsd[0-9][a-h] -compact
.It Pa /dev/sd[0-9][a-h]
block mode scsi disks
.It Pa /dev/rsd[0-9][a-h]
raw scsi disks
.El
.Sh DIAGNOSTICS
None.
.Sh SEE ALSO
.Xr disklabel 1
.Xr disklabel 5
.Xr fdisk 1
.Xr wd 4
.Xr dk 4
(on other systems)
.Sh HISTORY
The
.Nm
driver appeared in MACH 2.5 .

308
share/man/man4/st.4 Normal file
View file

@ -0,0 +1,308 @@
.Dd August 27, 1993
.Dt ST 4
.Os FreeBSD
.Sh NAME
.Nm st
.Nd scsi tape driver
.Sh SYNOPSIS
.Nm device-driver st
.Op Ar count
.Sh DESCRIPTION
The
.Xr st
driver provides support for a
.Em scsi
tape. It allows the tape
to be run in upto four different modes depending on minor numbers
and supports several different 'sub modes'.
The device can have both a
.Em raw
interface
and a
.Em Block mode
interface however only the raw interface is usually used (or recommended).
In general the interfaces are similar to those described by
.Xr wt 4
or
.Xr mt 4 .
.Pp
Where the
.Xr wt 4
device has a fairly low level interface to the system,
.Em SCSI
devices have a much higher level interface and talk to the system via
a
.Em SCSI Adapter
and a
.Em Scsi Adapter driver
e.g.
.Xr AHA1542 .
A scsi adapter must also be separatly configured into the system
before a scsi tape can be configured.
.Pp
As the scsi adapter is probed during boot, the
.Em SCSI
bus is scanned for devices. Any devices found which answer as 'Sequential'
type devices will be attached to the
.Nm
driver. The first found will be attached as
.Em st0
and the next,
.Em st1
etc.
.Pp
.Sh MOUNT SESSIONS
The
.Nm
driver is based around the concept of a
.Em Mount Session
, which is defined as the period between the time that a tape is mounted,
and the time when it is unmounted. Any parameters set during a
.Em Mount Session
remain in effect for the remainder of the session or until replaced. The
Tape can be unmounted, bringing the session to a close in several ways.
These include:
.Bl -tag -width ABOUT_THIS_BIG_BUT_REALLY_BIGGER
.It Pa closing an 'unmount device'
This is referred to as sub-mode 00 (see below). An example is /dev/rst0.
.It Pa an MTOFFL ioctl
Reachable throught the 'offline' command of
.Xr st 1
.It Pa Openning another mode.
Openning a different mode will implicitly unmount the tape, thereby closing
off the mode that was previously mounted. All parameters will be loaded
freshly from the new mode. (see below for more on 'modes').
.El
.Pp
Parameters that are required to last across the unmounting of a tape,
should be set on the control device. This is submode 3 (see below) and is
reached through a file with a name of the form /dev/st{y}ctl.{x}, where
{y} is the drive number and {x} is the mode number.
.Pp
.Sh MODES AND SUB MODES
There are four Operation modes. These are controlled by bits 2
and 3 of the minor number and are designed to allow people to easily
read and write different formats of tape on devices that allow
multiple formats. The parameters for each mode can be set individually
by hand with the
.Xr st 1
variant of the
.Xr mt 1
command. When a device corresponding to a particular mode is first mounted,
The operating parameters for that
.Em Mount Session
Are copied from that mode. Further changes to the parameters during the
session will change those in effect for the session but not those set
in the Operating Mode. To change the parameters for an Operating Mode,
One must either assign the parameters to the control device, or compile
them into the 'Rogues Gallery' table within the driver.
.Pp
In addition to the four Operation Modes mentionned above,
bits 0 and 1 of the minor number are interpretted as being 'sub-modes'.
The following sub-modes are supported
.Bl -tag -width ABOUT_THIS_BIG
.It Pa 00
A close will rewind the device. If the tape has been
written, then a Filemark will be written before the rewind is requested.
The device is UNMOUNTED.
.It Pa 01
A close will leave the tape MOUNTED.
If the tape was written to a filemark will be written.
No other head positioning takes place.
Any further reads or writes will occur directly after the
last read, or the written filemark.
.It Pa 10
A close will rewind the device. If the tape has been
written, then a Filemark will be written before the rewind is requested.
On completion of the rewind an UNLOAD command will be issued.
The device is UNMOUNTED.
.It Pa 11
This is a special mode.
It is known as the
.Em CONTROL DEVICE
for the mode. Parameters set for the mode while in this sub
mode will be remembered from one mount to the next. This allows the
system administrator to set different characteristics (e.g. density,
blocksize, (and eventually compression)) on each mode, and have the
different modes keep those parameters independent of any parameter
changes a user may invoke during a single mount session. At the
completion of the user's mount session, drive parameters will revert
to those set by the administrator. IO operations cannot be performed
on this device/submode. General
.Xr scsi 4
ioctls
.Em MUST
be performed against the control device.
.El
.Sh BLOCKING MODES
Scsi Tapes may run in either 'variable' or 'fixed block' modes.
Most QIC type devices run in Fixed block mode, where most 'reel to reel' tapes and
many new cartridge formats, allow variable blocksize. The difference between
the two is as follows:
.Bl -tag -width variable-blocksize
.It Pa Variable Blocksize
Each write made to the device results in a single logical record
written to the tape. You can never read or write PART of a record
from tape, (though you may request a larger block and read a smaller
record). You cannot read multiple blocks either. Data from a single
write is therefore read by a single read. The block size used may
be any value supported by the device, the scsi adapter and the
system. (often variable between 1 byte and 64k (sometimes more)).
.Pp
When reading a variable record/block from the tape, the head is
logically considered to be immediately after the last item read,
and before the next item after that. If the next item is a Filemark,
but you never read it because you have all the data, then the next
process to read will immediately read the filemark and return EOF.
(assuming you were in non-rewind mode).
.It Pa fixed Blocksize
Data written by the user is passed to the tape as a succession of
fixed size blocks. It may be contiguouse in ram and read in a single
DMA pass, however it is considered to be a series of independent
blocks. You may never write an amount of data that is not an exact
multiple of the blocksize. You may read and write the same data
as a different set of records, In other words, blocks that were
written together may be read separatly, and visa versa.
.Pp
If you ask for more blocks than there are left in the file, then
the drive will encounter the filemark. Because there is some data
to return to you (unless there were no records before the filemark)
the driver will return the data to you (less than you requested),
but hide from you the discovery of the Filemark. The NEXT read
will be returned immediately with an EOF. If you never Make the next
read, but close the device, the next process to read will immediately
read the filemark and return EOF. (assuming you were in non-rewind
mode).
.El
.Sh FILEMARK HANDLING
The handling of filemarks on write is pretty much automatic. If you
have written to the tape, and not done a read since, then a filemark will
be written to the tape when you close the device. If a rewind is requested
after a write, then the driver assumes that you have written the last file
on the tape and ensures that there are two filemarks written to the tape.
It takes into account any filemarks already written (whether by close
or by explicit ioctl). The exception to this is that there seems to be
a standard (which we follow, but don't understand why) that certain
types of tape do not actually write two filemarks to tape,
but when read, report a 'phantom' filemark when the last file is read.
These devices include the QIC family of devices. It might be that this
set of devices is the same set as that of fixed block devices. This has not
been detirmined yet, and they are treated as separate behaviors by the
driver at this time.
.Pp
.SH KERNEL CONFIGURATION
In configuring, if an optional
.Ar count
is given in
the specification, that number of scsi tapes are configured;
Most storage for them is allocated only when found so a large number
of configured devices is cheap. (once the first has included the driver).
.Pp
Because different tape drives behave differently, there is a mechanism
within the source to st, to quickly and conveniently recognise and deal
with brands and models of drive that have special requirements.
.Pp
There is a table (called the rogues gallery) in which the indentification
strings of known errant drives can be stored. Along with each is
a set of flags that allows the setting of densities and blocksizes for each
of the 4 modes, along with a set of 'QUIRK' flags that can be
used to enable or disable sections of code within the driver if a particular
drive is recognised.
.Pp
.Sh IOCTLS
The following
.Xr ioctl 2
calls apply to scsi tapes. Some also apply to other tapes. They are defined
in the header file
.Em /sys/mtio.h.
.Bl -tag -width MTIOCEEOT
.It Pa MTIOCGET
Get the mt control structure filled out by the driver, showing
all the present settings.
.It Pa MTIOCTOP
Perform one of the following operations. These operations all have a
single argument, which is either a boolean, or a signed integer, depending
on the operation.
.Bl -tag -width MTSELDNSTY
.It Pa MTWEOF
Write N end of file marks at the present head position.
.It Pa MTFSF
Skip over N Filemarks. Leave the head on the EOM side of the last skipped
Filemark.
.It Pa MTBSF
Skip BACKWARDS over N Filemarks. Leave the head on the BOM (beginning of media)
side of the last skipped Filemark.
.It Pa MTFSR
Skip forwards over N records.
.It Pa MTBSR
Skip backwards over N records.
.It Pa MTREW
Rewind the device to the beginning of the media.
.It Pa MTOFFL
Rewind the media (and if possible eject). Even if the device cannot
eject the media it will often no longer respond to normal requests.
.It Pa MTNOP
No Op, set status only..
.It Pa MTCACHE
Enable controller Buffering.
.It Pa MTNOCACHE
Disable controller Buffering.
.It Pa MTSETBSIZ
Set the blocksize to use for the device/mode. If the device is capable of
variable blocksize operation, and the blocksize is set to 0, then the drive
will be driven in variable mode. This parameter is in effect for the present
mount session only, unless set on the control device.
.It Pa MTSETDNSTY
Set the Density value (see
.Xr st 1
) to use when running in the mode openned (minor bits 2,3).
This parameter is in effect for the present
mount session only, unless set on the control device.
.El
.It Pa MTIOCIEOT
?Set END of TAPE processing... not yet supported.
.It Pa MTIOCEEOT
?Set END of TAPE processing... not yet supported.
.El
.Pp
In addition, The
.Nm
driver will allow the use of any of the general
.Xr scsi 4
ioctls, as long as the control device is used.
.Sh FILES
.Bl -tag -width /dev/[n][e]rst[0-9].[0-3] -compact
.It Pa /dev/[n][e]rst[0-9].[0-3]
general form:
.It Pa /dev/rst0.0
Mode 0, rewind on close
.It Pa /dev/nrst0.2
Mode 2, No rewind on close
.It Pa /dev/erst0.3
Mode 3, Eject on close (if capable)
.It Pa /dev/rst0
Another name for rst0.0
.It Pa /dev/nrst0
Another name for nrst0.0
.It Pa /dev/st0ctl.0
Parameters set to this device become the default parameters for [en]rst0.0
.It Pa /dev/st0ctl.1
Parameters set to this device become the default parameters for [en]rst0.1
.It Pa /dev/st0ctl.2
Parameters set to this device become the default parameters for [en]rst0.2
.It Pa /dev/st0ctl.3
Parameters set to this device become the default parameters for [en]rst0.3
.El
.Sh DIAGNOSTICS
None.
.Sh SEE ALSO
.Xr mt 1
.Xr st 1
.Sh HISTORY
This
.Nm
driver appeared in MACH 2.5 .

57
share/man/man4/su.4 Normal file
View file

@ -0,0 +1,57 @@
.Dd August 27, 1993
.Dt SU 4
.Os FreeBSD
.Sh NAME
.Nm su
.Nd scsi user-level driver
.Sh SYNOPSIS
.Nm device-driver su
.Sh DESCRIPTION
The
.Xr su
driver provides support for a
process to address arbitrary locations on the scsi bus. Minor
numbers are mapped 1:1 to bus:target:lun. The lowest three bits being LUN
and the next three bits being TARGET. Remaining bits are the bus number.
.Pp
A scsi adapter must also be separatly configured into the system
before this driver makes sense.
.Pp
.Sh THE SU DEVICE IS NOT COMPLETED YET
.Sh KERNEL CONFIGURATION
There are no configuration parameters for the su option. It'e either there
or it's not.
.Pp
.Sh IOCTLS
The
.Nm
driver has no ioctls of it's own but rather acts as a medium for the
generic
.Xr scsi 4
ioctls. These are described in
.Em sys/scsiio.h.
.Sh FILES
.Bl -tag -width /dev/su0-0-0XXXXXXXXXXX -compact
.It Pa /dev/su[0-9]-[0-7]-[0-7]
su{x}-{y}-{z} is the su device for the device at bus x, target y, lun z
.El
.Sh DIAGNOSTICS
All
.Xr scsi 4
debug ioclts work on
.Nm
devices.
.Sh SEE ALSO
.Xr sd 4
.Xr st 4
.Xr cd 4
.Xr uk 4
.Xr scsi 4
.Sh HISTORY
The
.Nm
driver appeared in 386BSD 0.1

60
share/man/man4/uk.4 Normal file
View file

@ -0,0 +1,60 @@
.Dd October 11, 1993
.Dt UK 4
.Os FreeBSD
.Sh NAME
.Nm uk
.Nd scsi user-level driver
.Sh SYNOPSIS
.Nm device-driver uk
.Sh DESCRIPTION
The
.Xr uk
driver provides support for a
process to address devices on the scsi bus for which there is no configured
driver.
.Nm
devices are numbered in the order they are found.
.Pp
A scsi adapter must also be separatly configured into the system
before this driver makes sense.
.Pp
.Sh KERNEL CONFIGURATION
If an count is given that number of
.Nm
devices will be configured into the kernel.
.Pp
.Sh IOCTLS
The
.Nm
driver has no ioctls of it's own but rather acts as a medium for the
generic
.Xr scsi 4
ioctls. These are described in
.Em sys/scsiio.h.
.Sh FILES
.Bl -tag -width /dev/uk0XXX -compact
.It Pa /dev/uk[0-255]
uk{x} is the 'xth'unknown device found.
.El
.Sh DIAGNOSTICS
All
.Xr scsi 4
debug ioclts work on
.Nm
devices.
.Sh SEE ALSO
.Xr sd 4
.Xr st 4
.Xr cd 4
.Xr ch 4
.Xr su 4
.Xr scsi 4
.Sh HISTORY
The
.Nm
driver appeared in 386BSD 0.1