Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!agate!tfs.com!mailhub!julian
From: julian@mailhub.tfs.com (Julian Elischer)
Subject: [2.0] Missing man pages (included)
Message-ID: <D2s2nx.C3r@tfs.com>
Summary: shar file of missing man pages
Sender: usenet@tfs.com (Mr. News)
Organization: TRW Financial Systems, Oakland, CA
References: <1995Jan21.174056.3751@robkaos.ruhr.de> <D2rxw3.B9C@tfs.com>
Date: Sat, 21 Jan 1995 23:02:21 GMT
Lines: 1007
Here are the man pages for the SCSI system, which were left out of the 2.0
distribution..
they are direct from the 1.1 distribution, and I need to do some editing
on them, but this will help out people who need them in the mean-while.
There are very few differences for 1.1 amd 2.0 so these should suffice..
they go in /usr/src/share/man/man4.
don't forget to add them to the Makefile there :)
julian
###############cut here #########################
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# cd.4
# st.4
# sd.4
# ch.4
# uk.4
# scsi.4
#
echo x - cd.4
sed 's/^X//' >cd.4 << 'END-of-cd.4'
X.Dd August 27, 1993
X.Dt CD 4
X.Os 386BSD/NetBSD
X.Sh NAME
X.Nm cd
X.Nd scsi cdrom driver
X.Sh SYNOPSIS
X.Nm device-driver cd
X.Op Ar count
X.Sh DESCRIPTION
XThe
X.Xr cd
Xdriver provides support for a
X.Em scsi
Xcdrom. It allows the cdrom
Xto be divided up into a set of pseudo devices called
X.Em partitions.
XIn an attempt to look like regular disks the
X.Nm
Xdriver synthesises a partition table, with one partition covering the entire
Xcdrom. A user might (for some amazing reason) add another partition to the
Xcdrom by using disklabel, but it will last only until the cdrom is unmounted.
XA Partition can have both a
X.Em raw
Xinterface
Xand a
X.Em Block mode
Xinterface.
XIn general the interfaces are similar to those described by
X.Xr wd 4
Xor
X.Xr sd 4 .
X
X.Pp
XWhere the
X.Xr wd 4
Xdevice has a fairly low level interface to the system,
X.Em SCSI
Xdevices have a much higher level interface and talk to the system via
Xa
X.Em SCSI Adapter
Xand a
X.Em Scsi Adapter driver
Xe.g.
X.Xr AHA1542 .
XA scsi adapter must also be separatly configured into the system
Xbefore a scsi cdrom can be configured.
X.Pp
XAs the scsi adapter is probed during boot, the
X.Em SCSI
Xbus is scanned for devices. Any devices found which answer as 'Readonly'
Xtype devices will be 'attached' to the
X.Nm
Xdriver. The first found will be attached as
X.Em cd0
Xand the next,
X.Em cd1
Xetc.
X.Pp
XThe system utility
X.Xr disklabel 1
Xmay be used to read the synthesized
X.Xr disklabel 5
Xstructure, which will contain correct figures for the size of the cdrom
Xshould that information be required.
X.Pp
X.Sh KERNEL CONFIGURATION
XAny number of cdroms may be attached to the system regardless of system
Xconfiguration as all resources are dynamically allocated.
X
X.Pp
X.Sh IOCTLS
XThe following
X.Xr ioctl 2
Xcalls apply to scsi cdroms
Xin the header files
X.Em sys/cdio.h.
Xand
X.Em sys/disklabel.h
X
X.Bl -tag -width CDIOCPLAYAUDIO____
X
X.It Dv DIOCGDINFO
XRead, from the kernel, the in-core copy of the disklabel for the
Xdrive. This will be a ficticious disklabel it will contain information
Xread from the scsi inquiry commands, and should be the same as
Xthe information printed at boot.
X.It Dv DIOCSDINFO
XGive the driver a new disklabel to use. The driver will NOT try write the new
Xdisklabel to the disk. (ok?)
X.It CDIOCPLAYTRACKS
XStart Audio playback given a track address and length.
X.It CDIOCPLAYBLOCKS
XStart Audio playback given a block address and length.
X.It CDIOCPLAYMSF
XStart Audio playback given a 'Minutes/ seconds/ frames' address and length.
X.It CDIOCREADSUBCHANNEL
XRead information from the subchannel at the location specified.
X.It CDIOREADTOCHEADER
XReturn summary information about the table of contents for the mounted cdrom.
X.It CDIOREADTOCENTRYS
XReturn information from the table of contents entries mentionned.
X.It CDIOCSETPATCH
XAttach various audio channels to various output channels.
X.It CDIOCGETVOL
XGet information about the volume settings of the output channels.
X.It CDIOCSETVOL
XChange the volume settings of the output channels.
X.It CDIOCSETMONO
XPatch all out[put channels to all source channels.
X.It CDIOCSETSTERIO
XPatch left source channel to the left output channel and the right
Xsource channel to the right output channel.
X.It CDIOCSETMUTE
XMute output without changing the volume settings.
X.It CDIOCSETLEFT
XAttach both output channels to the left source channel.
X.It CDIOCSETRIGHT
XAttach both output channels to the right source channel.
X.It CDIOCSETDEBUG
XTurn on debugging for the appropriate device.
X.It CDIOCCLRDEBUG
XTurn off debugging for the appropriate device.
X.It CDIOCPAUSE
XPause audio play, do not reset the location of the read-head.
X.It CDIOCRESUME
XResume audio play, Start at the location of the pause.
X.It CDIOCRESET
XReset the drive.
X.It CDIOCSTART
XTell the drive to spin-up the cdrom.
X.It CDIOCSTOP
XTell the drive to spin-down the cdrom.
X.It CDIOCEJECT
XEject the cdrom.
X.El
X.Pp
XIn addition the general
X.Xr scsi 4
Xioctls may be used with the
X.Nm
Xdriver, if used against the fourth (raw/whole disk) partiton. (e.g. rcd0d)
X.Sh NOTES
XWhen a cdrom is changed in a drive controlled by the
X.Nm
Xdriver, then the act of changing the media will invalidate the
Xdisklabel and information held within the kernel. To stop corruption,
XAll accesses to the device will be discarded until there are no more
Xopen file descriptors referencing the device. During this period, all
Xnew open attempts will be rejected. When No more open file descriptors
Xreference the device, the first next open will load a new set of
Xfigures (including disklabel) for the drive.
X
XThe Audio code in the
X.Nm
Xdriver only support SCSI2 standard audio commands. As there are many cdrom
Xmanufacturers who have not followed the standard well, there are many
Xcdroms for which audio will not work. Some work is planned to support
Xsome of the more common 'broken' cdrom drives however this is not yet
Xunder way.
X
X.Sh FILES
X.Bl -tag -width /dev/rcd[0-9][a-h] -compact
X.It Pa /dev/cd[0-9][a-h]
Xblock mode scsi disks
X.It Pa /dev/rcd[0-9][a-h]
Xraw scsi disks
X.El
X.Sh DIAGNOSTICS
XNone.
X.Sh SEE ALSO
X.Xr disklabel 1
X.Xr disklabel 5
X.Xr wd 4
X.Xr sd 4
X.Sh HISTORY
XThis
X.Nm
Xdriver appeared in 386BSD 0.1.
END-of-cd.4
echo x - st.4
sed 's/^X//' >st.4 << 'END-of-st.4'
X.Dd August 27, 1993
X.Dt ST 4
X.Os 386BSD/NetBSD
X.Sh NAME
X.Nm st
X.Nd scsi tape driver
X.Sh SYNOPSIS
X.Nm device-driver st
X.Op Ar count
X.Sh DESCRIPTION
XThe
X.Xr st
Xdriver provides support for a
X.Em scsi
Xtape. It allows the tape
Xto be run in upto four different modes depending on minor numbers
Xand supports several different 'sub modes'.
XThe device can have both a
X.Em raw
Xinterface
Xand a
X.Em Block mode
Xinterface however only the raw interface is usually used (or recommended).
XIn general the interfaces are similar to those described by
X.Xr wt 4
Xor
X.Xr mt 4 .
X
X.Pp
XWhere the
X.Xr wt 4
Xdevice has a fairly low level interface to the system,
X.Em SCSI
Xdevices have a much higher level interface and talk to the system via
Xa
X.Em SCSI Adapter
Xand a
X.Em Scsi Adapter driver
Xe.g.
X.Xr AHA1542 .
XA scsi adapter must also be separatly configured into the system
Xbefore a scsi tape can be configured.
X.Pp
XAs the scsi adapter is probed during boot, the
X.Em SCSI
Xbus is scanned for devices. Any devices found which answer as 'Sequential'
Xtype devices will be attached to the
X.Nm
Xdriver. The first found will be attached as
X.Em st0
Xand the next,
X.Em st1
Xetc.
X.Pp
X.Sh MOUNT SESSIONS
XThe
X.Nm
Xdriver is based around the concept of a
X.Em Mount Session
X, which is defined as the period between the time that a tape is mounted,
Xand the time when it is unmounted. Any parameters set during a
X.Em Mount Session
Xremain in effect for the remainder of the session or until replaced. The
XTape can be unmounted, bringing the session to a close in several ways.
XThese include:
X.Bl -tag -width ABOUT_THIS_BIG_BUT_REALLY_BIGGER
X.It Pa closing an 'unmount device'
XThis is referred to as sub-mode 00 (see below). An example is /dev/rst0.
X.It Pa an MTOFFL ioctl
XReachable throught the 'offline' command of
X.Xr st 1
X.It Pa Openning another mode.
XOpenning a different mode will implicitly unmount the tape, thereby closing
Xoff the mode that was previously mounted. All parameters will be loaded
Xfreshly from the new mode. (see below for more on 'modes').
X.El
X.Pp
XParameters that are required to last across the unmounting of a tape,
Xshould be set on the control device. This is submode 3 (see below) and is
Xreached through a file with a name of the form /dev/st{y}ctl.{x}, where
X{y} is the drive number and {x} is the mode number.
X.Pp
X.Sh MODES AND SUB MODES
XThere are four Operation modes. These are controlled by bits 2
Xand 3 of the minor number and are designed to allow people to easily
Xread and write different formats of tape on devices that allow
Xmultiple formats. The parameters for each mode can be set individually
Xby hand with the
X.Xr st 1
Xvariant of the
X.Xr mt 1
Xcommand. When a device corresponding to a particular mode is first mounted,
XThe operating parameters for that
X.Em Mount Session
XAre copied from that mode. Further changes to the parameters during the
Xsession will change those in effect for the session but not those set
Xin the Operating Mode. To change the parameters for an Operating Mode,
XOne must either assign the parameters to the control device, or compile
Xthem into the 'Rogues Gallery' table within the driver.
X.Pp
XIn addition to the four Operation Modes mentionned above,
Xbits 0 and 1 of the minor number are interpretted as being 'sub-modes'.
XThe following sub-modes are supported
X.Bl -tag -width ABOUT_THIS_BIG
X.It Pa 00
XA close will rewind the device. If the tape has been
Xwritten, then a Filemark will be written before the rewind is requested.
XThe device is UNMOUNTED.
X.It Pa 01
XA close will leave the tape MOUNTED.
XIf the tape was written to a filemark will be written.
XNo other head positioning takes place.
XAny further reads or writes will occur directly after the
Xlast read, or the written filemark.
X.It Pa 10
XA close will rewind the device. If the tape has been
Xwritten, then a Filemark will be written before the rewind is requested.
XOn completion of the rewind an UNLOAD command will be issued.
XThe device is UNMOUNTED.
X.It Pa 11
XThis is a special mode.
XIt is known as the
X.Em CONTROL DEVICE
Xfor the mode. Parameters set for the mode while in this sub
Xmode will be remembered from one mount to the next. This allows the
Xsystem administrator to set different characteristics (e.g. density,
Xblocksize, (and eventually compression)) on each mode, and have the
Xdifferent modes keep those parameters independent of any parameter
Xchanges a user may invoke during a single mount session. At the
Xcompletion of the user's mount session, drive parameters will revert
Xto those set by the administrator. IO operations cannot be performed
Xon this device/submode. General
X.Xr scsi 4
Xioctls
X.Em MUST
Xbe performed against the control device.
X.El
X.Sh BLOCKING MODES
XScsi Tapes may run in either 'variable' or 'fixed block' modes.
XMost QIC type devices run in Fixed block mode, where most 'reel to reel' tapes and
Xmany new cartridge formats, allow variable blocksize. The difference between
Xthe two is as follows:
X.Bl -tag -width variable-blocksize
X.It Pa Variable Blocksize
XEach write made to the device results in a single logical record
Xwritten to the tape. You can never read or write PART of a record
Xfrom tape, (though you may request a larger block and read a smaller
Xrecord). You cannot read multiple blocks either. Data from a single
Xwrite is therefore read by a single read. The block size used may
Xbe any value supported by the device, the scsi adapter and the
Xsystem. (often variable between 1 byte and 64k (sometimes more)).
X.Pp
XWhen reading a variable record/block from the tape, the head is
Xlogically considered to be immediately after the last item read,
Xand before the next item after that. If the next item is a Filemark,
Xbut you never read it because you have all the data, then the next
Xprocess to read will immediately read the filemark and return EOF.
X(assuming you were in non-rewind mode).
X.It Pa fixed Blocksize
XData written by the user is passed to the tape as a succession of
Xfixed size blocks. It may be contiguouse in ram and read in a single
XDMA pass, however it is considered to be a series of independent
Xblocks. You may never write an amount of data that is not an exact
Xmultiple of the blocksize. You may read and write the same data
Xas a different set of records, In other words, blocks that were
Xwritten together may be read separatly, and visa versa.
X.Pp
XIf you ask for more blocks than there are left in the file, then
Xthe drive will encounter the filemark. Because there is some data
Xto return to you (unless there were no records before the filemark)
Xthe driver will return the data to you (less than you requested),
Xbut hide from you the discovery of the Filemark. The NEXT read
Xwill be returned immediately with an EOF. If you never Make the next
Xread, but close the device, the next process to read will immediately
Xread the filemark and return EOF. (assuming you were in non-rewind
Xmode).
X.El
X.Sh FILEMARK HANDLING
XThe handling of filemarks on write is pretty much automatic. If you
Xhave written to the tape, and not done a read since, then a filemark will
Xbe written to the tape when you close the device. If a rewind is requested
Xafter a write, then the driver assumes that you have written the last file
Xon the tape and ensures that there are two filemarks written to the tape.
XIt takes into account any filemarks already written (whether by close
Xor by explicit ioctl). The exception to this is that there seems to be
Xa standard (which we follow, but don't understand why) that certain
Xtypes of tape do not actually write two filemarks to tape,
Xbut when read, report a 'phantom' filemark when the last file is read.
XThese devices include the QIC family of devices. It might be that this
Xset of devices is the same set as that of fixed block devices. This has not
Xbeen detirmined yet, and they are treated as separate behaviors by the
Xdriver at this time.
X.Pp
X.SH KERNEL CONFIGURATION
XIn configuring, if an optional
X.Ar count
Xis given in
Xthe specification, that number of scsi tapes are configured;
XMost storage for them is allocated only when found so a large number
Xof configured devices is cheap. (once the first has included the driver).
X.Pp
XBecause different tape drives behave differently, there is a mechanism
Xwithin the source to st, to quickly and conveniently recognise and deal
Xwith brands and models of drive that have special requirements.
X.Pp
XThere is a table (called the rogues gallery) in which the indentification
Xstrings of known errant drives can be stored. Along with each is
Xa set of flags that allows the setting of densities and blocksizes for each
Xof the 4 modes, along with a set of 'QUIRK' flags that can be
Xused to enable or disable sections of code within the driver if a particular
Xdrive is recognised.
X.Pp
X.Sh IOCTLS
XThe following
X.Xr ioctl 2
Xcalls apply to scsi tapes. Some also apply to other tapes. They are defined
Xin the header file
X.Em /sys/mtio.h.
X
X.Bl -tag -width MTIOCEEOT
X.It Pa MTIOCGET
XGet the mt control structure filled out by the driver, showing
Xall the present settings.
X.It Pa MTIOCTOP
XPerform one of the following operations. These operations all have a
Xsingle argument, which is either a boolean, or a signed integer, depending
Xon the operation.
X.Bl -tag -width MTSELDNSTY
X.It Pa MTWEOF
XWrite N end of file marks at the present head position.
X.It Pa MTFSF
XSkip over N Filemarks. Leave the head on the EOM side of the last skipped
XFilemark.
X.It Pa MTBSF
XSkip BACKWARDS over N Filemarks. Leave the head on the BOM (beginning of media)
Xside of the last skipped Filemark.
X.It Pa MTFSR
XSkip forwards over N records.
X.It Pa MTBSR
XSkip backwards over N records.
X.It Pa MTREW
XRewind the device to the beginning of the media.
X.It Pa MTOFFL
XRewind the media (and if possible eject). Even if the device cannot
Xeject the media it will often no longer respond to normal requests.
X.It Pa MTNOP
XNo Op, set status only..
X.It Pa MTCACHE
XEnable controller Buffering.
X.It Pa MTNOCACHE
XDisable controller Buffering.
X.It Pa MTSETBSIZ
XSet the blocksize to use for the device/mode. If the device is capable of
Xvariable blocksize operation, and the blocksize is set to 0, then the drive
Xwill be driven in variable mode. This parameter is in effect for the present
Xmount session only, unless set on the control device.
X.It Pa MTSETDNSTY
XSet the Density value (see
X.Xr st 1
X) to use when running in the mode openned (minor bits 2,3).
XThis parameter is in effect for the present
Xmount session only, unless set on the control device.
X.El
X.It Pa MTIOCIEOT
X?Set END of TAPE processing... not yet supported.
X.It Pa MTIOCEEOT
X?Set END of TAPE processing... not yet supported.
X.El
X.Pp
XIn addition, The
X.Nm
Xdriver will allow the use of any of the general
X.Xr scsi 4
Xioctls, as long as the control device is used.
X
X.Sh FILES
X.Bl -tag -width /dev/[n][e]rst[0-9].[0-3] -compact
X.It Pa /dev/[n][e]rst[0-9].[0-3]
Xgeneral form:
X.It Pa /dev/rst0.0
XMode 0, rewind on close
X.It Pa /dev/nrst0.2
XMode 2, No rewind on close
X.It Pa /dev/erst0.3
XMode 3, Eject on close (if capable)
X.It Pa /dev/rst0
XAnother name for rst0.0
X.It Pa /dev/nrst0
XAnother name for nrst0.0
X.It Pa /dev/st0ctl.0
XParameters set to this device become the default parameters for [en]rst0.0
X.It Pa /dev/st0ctl.1
XParameters set to this device become the default parameters for [en]rst0.1
X.It Pa /dev/st0ctl.2
XParameters set to this device become the default parameters for [en]rst0.2
X.It Pa /dev/st0ctl.3
XParameters set to this device become the default parameters for [en]rst0.3
X.El
X.Sh DIAGNOSTICS
XNone.
X.Sh SEE ALSO
X.Xr mt 1
X.Xr st 1
X.Sh HISTORY
XThis
X.Nm
Xdriver appeared in MACH 2.5 .
X
END-of-st.4
echo x - sd.4
sed 's/^X//' >sd.4 << 'END-of-sd.4'
X.Dd August 27, 1993
X.Dt SD 4
X.Os 386BSD/NetBSD
X.Sh NAME
X.Nm sd
X.Nd scsi disk driver
X.Sh SYNOPSIS
X.Nm device-driver sd
X.Op Ar count
X.Sh DESCRIPTION
XThe
X.Xr sd
Xdriver provides support for a
X.Em scsi
Xdisk. It allows the disk
Xto be divided up into a set of pseudo devices called
X.Em partitions.
XA Partition can have both a
X.Em raw
Xinterface
Xand a
X.Em Block mode
Xinterface.
XIn general the interfaces are similar to those described by
X.Xr wd 4
Xor
X.Xr dk 4 .
X
X.Pp
XWhere the
X.Xr wd 4
Xdevice has a fairly low level interface to the system,
X.Em SCSI
Xdevices have a much higher level interface and talk to the system via
Xa
X.Em SCSI Adapter
Xand a
X.Em Scsi Adapter driver
Xe.g.
X.Xr AHA1542 .
XA scsi adapter must also be separatly configured into the system
Xbefore a scsi disk can be configured.
X.Pp
XAs the scsi adapter is probed during boot, the
X.Em SCSI
Xbus is scanned for devices. Any devices found which answer as 'Direct'
Xtype devices will be 'attached' to the
X.Nm
Xdriver. The first found will be attached as
X.Em sd0
Xand the next,
X.Em sd1
Xetc.
X.Pp
X.Sh PARTITIONING
XThe
X.Nm
Xdriver allows the disk to have two levels of partitioning.
XOne which allows it to have
Xpartitions for different Operating systems, (one of which is BSD unix),
X(see also for the 386 port,
X.Xr fdisk 1
X), and within a BSD partition, further partitions which are individually
Xaddressable as separate entries in the
X.Em /dev
Xdirectory. The second level of partitioning is controlled by the program
X.Xr disklabel 1
Xand is common in format across most BSD operating systems. In most of
Xthe original BSD ports, what is the
XBSD part here, is the entire disk, and the outer layer of partitionning
Xdoes not exist.
X.Nm
Xwill also run in this manner if
X.Xr disklabel 1
Xis run with a blank disk, without first partitioning it
Xwith
X.Xr fdisk 1
X(or similar).
X
X.Pp
XApologies for the two conflicting usages of the word Partition, but
Xit's a historical artifact, and the meaning must be judged from context
Xin each case. The next paragraph will discuss partitions exclusively
Xin the context of WITHIN a BSD partition on the disk.
X.Pp
XThe first few blocks of the BSD section (maybe all) of the disk contain
Xsome boot code, and a structure, known as the
X.Xr disklabel 5
Xwhich describes the disk's characteristics and partitioning for BSD.
XIt is set up by the
X.Xr disklabel 1
Xprogram, and read in by the kernel when the device is first initialised
Xduring boot. It describes how the drive is further divided. The
X.Xr disklabel 5
Xstructure contains room for 8 (usually) partitions. Usually these
Xpartitions are calculated so as to fall evenly on cylinder boundaries,
Xhowever on a
X.Em SCSI
Xdisk this is sometimes not possible. The reason for doing this is historically
Xto get better performance, however modern
X.Em SCSI
Xdisks often have a variable format, so that it is hard to know at any point
Xin the disk, where the cylinder or track boundaries are. Added to this, the
Xfact that
X.Em SCSI
Xdisk blocks are addressed soley by their 'block number' and not by
Xany geometry, leads to the common occurance on
X.Em SCSI
Xdisks, of laying out partitions on arbitrary boundaries. Because
Xmodern disks often have large track caches, this often leads to only small
Xdegadations of performance, and is in fact sometimes unavoidable. The
Xboot messages will suggest a geometry similar in heads and cylinders
Xto the real geometry, but the disklable need not agree with this for the
Xsystem to be able to successfully work with the disk.
X.Pp
XDuring booting
Xwith an uninitialised disk, the
X.Nm
Xdriver will initialise the 'in-core' copy of the disklabel to the suggested
Xvalues, however they are not written to the disk.
X.Pp
XThe fourth partition is special. No matter what the disklabel
Xsays, the fourth partition (partition d) reflectls the entire disk, including
Xthose areas OUTSIDE the BSD partitions. At some times it is suggested that
Xthe c partition might be used to represent the entire BSD partition, so these
Xtwo partitions should be avoided when laying out filesystems. The fourth
Xpartition must be used for general
X.Xr scsi 4
Xioctls.
X.Pp
XWhile partitions are only theoretically valid within the BSD partition, they
Xare specified in terms of absolute block numbers, so it is possible to
Xspecify a partition that lies outside of the BSD partition. This is useful
Xif one wants to have a /dev entry that points to a partition belonging
Xto another OS (e.g. DOS).
X.Pp
X.Sh KERNEL CONFIGURATION
XIn configuring, if an optional
X.Ar count
Xis given in
Xthe specification, that number of scsi disks are configured;
XMost storage for them is allocated only when found so a large number
Xof configured devices is cheap. (once the first has included the driver).
X
X.Pp
X.Sh IOCTLS
XThe following
X.Xr ioctl 2
Xcalls apply to scsi disks as well as to other disks. They are defined
Xin the header file
X.Em disklabel.h.
X
X.Bl -tag -width DIOCSDINFO
X
X.It Dv DIOCSBAD
XUsually used to set up a bad-block mapping system on the disk. Scsi
Xdrive incorporate their own bad-block mapping so this is not implimented,
Xhowever it MAY be implimented in the future as a 'kludged' interface to the
Xscsi bad-block mapping.
X.It Dv DIOCGDINFO
XRead, from the kernel, the in-core copy of the disklabel for the
Xdrive. This may be a ficticious disklabel if the drive has never
Xbeen initialised, in which case it will contain information read
Xfrom the scsi inquiry commands, and should be the same as
Xthe information printed at boot.
X.It Dv DIOCSDINFO
XGive the driver a new disklabel to use. The driver will NOT try write the new
Xdisklabel to the disk.
X.It Dv DIOCWLABEL
XEnable or Disable the driver's software
Xwrite protect of the disklabel on the disk.
X.It Dv DIOCWDINFO
XGive the driver a new disklabel to use. The driver WILL try write the new
Xdisklabel to the disk.
X.El
X.Pp
XIn addition, the
X.Xr scsi 4
Xgeneral ioctls may be used with the
X.Nm
Xdriver, but only against the fourth (whole disk) partition.
X.Sh NOTES
XIf a removable device is attached to the
X.Nm
Xdriver, then the act of changing the media will invalidate the
Xdisklabel and information held within the kernel. To stop corruption,
XAll accesses to the device will be discarded until there are no more
Xopen file descriptors referencing the device. During this period, all
Xnew open attempts will be rejected. When No more open file descriptors
Xreference the device, the first next open will load a new set of
Xfigures (including disklabel) for the drive.
X
XAn ioctl to map out a bad block is planned. (the code is already present
Xin the driver).
X
X.Sh FILES
X.Bl -tag -width /dev/rsd[0-9][a-h] -compact
X.It Pa /dev/sd[0-9][a-h]
Xblock mode scsi disks
X.It Pa /dev/rsd[0-9][a-h]
Xraw scsi disks
X.El
X.Sh DIAGNOSTICS
XNone.
X.Sh SEE ALSO
X.Xr disklabel 1
X.Xr disklabel 5
X.Xr fdisk 1
X.Xr wd 4
X.Xr dk 4
X(on other systems)
X.Sh HISTORY
XThe
X.Nm
Xdriver appeared in MACH 2.5 .
X
END-of-sd.4
echo x - ch.4
sed 's/^X//' >ch.4 << 'END-of-ch.4'
X.Dd August 27, 1993
X.Dt CH 4
X.Os 386BSD/NetBSD
X.Sh NAME
X.Nm ch
X.Nd scsi media-changer (juke box) driver
X.Sh SYNOPSIS
X.Nm device-driver ch
X.Op Ar count
X.Sh DESCRIPTION
XThe
X.Xr ch
Xdriver provides support for a
X.Em scsi
Xjuke box. It allows many slots of media to be multiplexed between a number
Xof drives.
X.Pp
XA scsi adapter must also be separatly configured into the system
Xbefore a scsi changer can be configured.
X.Pp
XAs the scsi adapter is probed during boot, the
X.Em SCSI
Xbus is scanned for devices. Any devices found which answer as 'Changer'
Xtype devices will be 'attached' to the
X.Nm
Xdriver. The first found will be attached as
X.Em ch0
Xand the next,
X.Em ch1
Xetc.
X.Pp
X
X.Sh KERNEL CONFIGURATION
XIn configuring, if an optional
X.Ar count
Xis given in the specification, that number of scsi media changers
Xare configured; Most storage for them is allocated only when found
Xso a large number of configured devices is cheap. (once the first
Xhas included the driver).
X
X.Pp
X.Sh IOCTLS
XThe following
X.Xr ioctl 2
Xcall applies to the changer. It is defined in
Xin the header file
X.Em sys/chio.h.
X
X.Bl -tag -width DIOCSDINFO
XCHIOOP
XThis appears to be a 'do-everything' call.
X.El
X.Sh NOTES
XThe
X.Nm
Xdriver was added to the system by
X Stefan Grefen (grefen@goofy.zdv.uni-mainz.de)
Xwho apparently had such a device
Xhowever It appears as though no-one I have heard of has ever used this
Xdriver. If you use it please let me know so I can test changes.
XStefan appears to have suffered net.death (or at least net.disconnection).
XI (julian) have never used this device. If you do please re-write this
Xman page and send it to me..
X
X.Sh FILES
X.Bl -tag -width /dev/ch[0-9] -compact
X.It Pa /dev/ch[0-9]
Xdevice entries
X.El
X.Sh DIAGNOSTICS
XNone.
X.Sh SEE ALSO
X.Xr sd 4
X.Xr st 4
X.Xr cd 4
X.Sh HISTORY
XThe
X.Nm
Xdriver appeared in 386BSD 0.1
X
END-of-ch.4
echo x - uk.4
sed 's/^X//' >uk.4 << 'END-of-uk.4'
X.Dd October 11, 1993
X.Dt UK 4
X.Os 386BSD/NetBSD
X.Sh NAME
X.Nm uk
X.Nd scsi user-level driver
X.Sh SYNOPSIS
X.Nm device-driver uk
X.Sh DESCRIPTION
XThe
X.Xr uk
Xdriver provides support for a
Xprocess to address devices on the scsi bus for which there is no configured
Xdriver.
X.Nm
Xdevices are numbered in the order they are found.
X.Pp
XA scsi adapter must also be separatly configured into the system
Xbefore this driver makes sense.
X.Pp
X.Sh KERNEL CONFIGURATION
XIf an count is given that number of
X.Nm
Xdevices will be configured into the kernel.
X
X
X.Pp
X.Sh IOCTLS
XThe
X.Nm
Xdriver has no ioctls of it's own but rather acts as a medium for the
Xgeneric
X.Xr scsi 4
Xioctls. These are described in
X.Em sys/scsiio.h.
X
X
X.Sh FILES
X.Bl -tag -width /dev/uk0XXX -compact
X.It Pa /dev/uk[0-255]
Xuk{x} is the 'xth'unknown device found.
X.El
X.Sh DIAGNOSTICS
XAll
X.Xr scsi 4
Xdebug ioclts work on
X.Nm
Xdevices.
X.Sh SEE ALSO
X.Xr sd 4
X.Xr st 4
X.Xr cd 4
X.Xr ch 4
X.Xr su 4
X.Xr scsi 4
X.Sh HISTORY
XThe
X.Nm
Xdriver appeared in 386BSD 0.1
X
END-of-uk.4
echo x - scsi.4
sed 's/^X//' >scsi.4 << 'END-of-scsi.4'
X.Dd August 27, 1993
X.Dt SD 4
X.Os 386BSD/NetBSD
X.Sh NAME
X.Nm scsi
X.Nd scsi system
X.Sh SYNOPSIS
X.Nm device-driver scbus
X.Sh DESCRIPTION
XThe
X.Em scsi
Xsystem provides a uniform and modular system for the implimentation
Xof drivers to control various scsi devices, and to utilise different
Xscsi adapters through adapter drivers. When the system probes the
X.Em SCSI
Xbusses, it attaches any devices it finds to the appropriate
Xdrivers. If no driver seems appropriate, then at attaches the device to the
Xuk (unknown) driver (if configured), so that user level scsi ioctls may
Xstill be performed against the device.
X.Sh KERNEL CONFIGURATION
XContinuously changing. check your nearest bsd mailing list.
XThe option SCSIDEBUG enables the debug ioctl.
X.Sh IOCTLS
XThere are a number of ioctls that will (when the next stage is complete)
Xwork on any
X.Em SCSI
Xdevice. They are defined in
X.Em sys/scsiio.h
Xand can be applied against any scsi device that allows both read and write,
Xthough for devices such as tape, it must be applied against the control
Xdevice. See the manual page for each device type for more information about
Xhow generic scsi ioctls may be applied to a specific device.
X.Bl -tag -width DIOCSDINFO____
X.It Dv SCIOCRESET*
Xreset a device.
X.It Dv SCIOCDEBUG
XTurn on debugging.. All scsi operations originating from this device's driver
Xwill be traced to the console, along with other information. Debugging is
Xcontrolled by four bits, described in the header file. If no debugging is
Xconfigured into the kernel, debugging will have no effect.
X.Em SCSI
Xdebugging is controlled by the configuration option
X.Em SCSIDEBUG.
X.It Dv SCIOCCOMMAND
XTake a scsi command and data from a user process and apply them to the scsi
Xdevice. Return all status information and return data to the process. The
Xioctl will return a successful status even if the device rejected the
Xcommand. As all status is returned to the user, it is up to the user
Xprocess to examine this information to decide the success of the command.
X.It Dv SCIOCREPROBE
XAsk the system to probe the scsi busses for any new devices. If it finds
Xany, they will be attached to the appropriate drivers. The search can be
Xnarrowed to a specific bus, target or lun. The new device may or may not
Xbe related to the device on which the ioctl was performed.
X.It Dv SCIOCIDENTIFY
XAsk the driver what it's bus, target and lun are.
X.It Dv SCIOCDECONFIG
XAsk the device to dissappear. This may not happen if the device is in use.
X.El
X.Sh NOTES
Xthe generic scsi part of the system is still being mapped out.
XWatch this space for changes.
X.Pp
X A device by the name of su (scsi_user)
X(e.g su0-0-0) will map bus, target and lun to minor numbers. I have not
Xyet decided yet whether this device will be able to open a device that is
Xalready controlled by an explicit driver.
X.Sh ADAPTERS
XThe system allows common device drivers to work through many different
Xtypes of adapters. The adapters take requests from the upper layers and do
Xall IO between the
X.Em SCSI
Xbus and the system. The maximum size of a transfer is governed by the
Xadapter. Most adapters can transfer 64KB in a single operation, however
Xmany can transfer larger amounts.
X.Sh TARGET MODE
XSome adapters support
X.Em Target mode
Xin which the system is capable of operating as a device, responding to
Xoperations initioated by another system. Target mode will be supported for
Xsome adapters, but is not yet complete for this version of the scsi system.
X.Sh FILES
Xsee other scsi device entries.
X.Sh DIAGNOSTICS
XWhen the kernel is compiled with option SCSIDEBUG, the SCIOCDEBUG ioctl
Xcan be used to enable various amounts of tracing information on any
Xspecific device. Devices not being traced will not produce trace information.
XThe four bits that make up the debug level, each control certain types
Xof debugging information.
X.Bl -tag -width THIS_WIDE_PLEASE
X.It Dv Bit 0
XBit 0 shows all scsi bus operations including scsi commands,
Xerror information and the first 48 bytes of any data transferred.
X.It Dv Bit 1
XBit 1 shows routines called.
X.It Dv Bit 2
XBit 2 shows information about what branches are taken and often some
Xof the return values of functions.
X.It Dv Bit 3
XBit 3 shows more detailed information including DMA scatter-gather logs.
X.El
X.Sh SEE ALSO
X.Xr ch 4
X.Xr cd 4
X.Xr sd 4
X.Xr st 4
X.Xr uk 4
X.Xr su 4
X.Xr aha 4
X.Xr ahb 4
X.Xr bt 4
X.Xr uha 4
X.Sh HISTORY
XThis
X.Nm
Xsystem appeared in MACH 2.5 at TRW.
X
END-of-scsi.4
exit