.Cd "scsibus at ..."
.Cd "cd* at scsibus?"
.Cd "ch* at scsibus?"
.Cd "safte* at scsibus?"
.Cd "sd* at scsibus?"
.Cd "ses* at scsibus?"
.Cd "st* at scsibus?"
.Cd "ss* at scsibus?"
.Cd "uk* at scsibus?"
DESCRIPTION
The
SCSI
system provides a uniform and modular system for the implementation
of drivers to control various scsi devices, and to utilize different
scsi host adapters through host adapter drivers.
When the system probes the
SCSI
buses, it attaches any devices it finds to the appropriate
drivers.
If no driver seems appropriate, then it attaches the device to the
uk (unknown) driver so that user level scsi ioctls may
still be performed against the device.
KERNEL CONFIGURATION
The option SCSIDEBUG enables the debug ioctl.
All devices and the SCSI buses support boot time allocation so that
an upper number of devices and controllers does not need to be configured;
.Cd "sd* at scsibus?"
will suffice for any number of disk drivers.
The devices are either
wired
so they appear as a particular device unit or
counted
so that they appear as the next available unused unit.
To configure a driver in the kernel without wiring down the device use a
config line similar to
.Cd "ch* at scsibus?"
to include the changer driver.
To wire down a unit use a config line similar to
.Cd "ch1 at scsibus0 target 4 lun 0"
to assign changer 1 as the changer with SCSI ID 4,
SCSI logical unit 0 on SCSI bus 0.
Individual scsibuses can be wired down to specific controllers with
a config line similar to
.Cd "scsibus0 at ahc0"
which assigns scsi bus 0 to the first unit using the ahc driver.
For controllers supporting more than one bus,
the particular bus can be specified as in
.Cd "scsibus3 at ahc1 bus 1"
which assigns scsibus 1 to the second bus probed on the ahc1 device.
When there is a mixture of wired down and counted devices then the
counting begins with the first non-wired down unit for a particular
type.
That is, if a disk is wired down as
.Cd "sd1 at scsibus?" ,
then the first non-wired disk shall come on line as
sd2.
IOCTLS
There are a number of ioctls that work on any
SCSI
device.
They are defined in
sys/scsiio.h
and can be applied against any scsi device that permits them.
For the 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.
SCIOCRESET*
Reset a device.
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.
SCSI
debugging is controlled by the configuration option
SCSIDEBUG.
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.
SCIOCIDENTIFY
Ask the driver what its bus, target and lun are.
In addition, the device type, ATAPI or SCSI, is returned.
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 I/O between the
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, and many can transfer
larger amounts.
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.
Bit0
shows all scsi bus operations including scsi commands,
error information and the first 48 bytes of any data transferred.
Bit1
shows routines called.
Bit2
shows information about what branches are taken and often some
of the return values of functions.
Bit3
shows more detailed information including DMA scatter-gather logs.