                      README for sg3_utils
                      ====================
Introduction
============
This package contains low level utilities for devices that use a SCSI
command set. Apart from SCSI parallel interface (SPI) devices, the SCSI
command set is used by ATAPI devices (CD/DVDs and tapes), USB mass storage
devices, Fibre Channel disks, IEEE 1394 storage devices (that use the
"SBP" protocol), SAS, iSCSI and FCoE devices (amongst others).

This package originally targeted the Linux SCSI subsystem. Since most
operating systems contain a SCSI command pass-through mechanism, many
utilities within this package have been ported. This README mainly
concentrates on Linux: see the README.freebsd file for the FreeBSD port,
README.solaris for the Solaris port, the README.tru64 file for the Tru64
(OSF) port and README.win32 for the Windows ports (of which there are two).

Most utilities within the sg3_utils package work at the SCSI command level.
For example the sg_inq utility issues a SCSI INQUIRY command and decodes the
response. The COVERAGE file has a table containing a row for each SCSI
command issued by this package; to the right of each row is the utility
(sometimes more than one) that issue that SCSI command. The COVERAGE file
has a second table for ATA commands issude.

Some utilities interface at a slightly higher level, for example: sg_dd,
sgm_dd and sgp_dd. These are closely related to the Unix dd command and
typically issue a sequence of SCSI READ and WRITE commands to copy data.
These utilities are relatively tightly bound to Linux and are not ported to
other Operating Systems. A new utility called ddpt (in a package of the same
name) is more generic while still allowing a copy to be done in terms of
SCSI READ and WRITE commands. ddpt has been ported to other OSes.

Description
===========
A web site supporting the sg3_utils package can be found at
http://sg.danny.cz/sg/sg3_utils.html . That page has a table of released
versions for download. The most recent release or beta of sg3_utils may
be found on this page: http://sg.danny.cz/sg in the News section.

The predecessor to this package was called sg_utils. It is described in
http://sg.danny.cz/sg/uu_index.html and old versions can be downloaded
from the Downloads section of http://sg.danny.cz/sg .

In the Linux 2.4 kernel series these utilities need to use the SCSI generic
(sg) driver to access SCSI devices. The name of this package (i.e. sg3_utils)
refers to version 3 of the SCSI generic (sg) driver which was introduced at
the beginning of the 2.4 Linux kernel series. Significantly this added a new
SCSI command interface structure (i.e. struct sg_io_hdr) that is more
flexible than the older "sg_header" structure found in the sg driver in the
2.2 and earlier Linux kernel series. The sg_io_hdr structure is also more
flexible than the awkward (and limiting) interface to the
SCSI_IOCTL_SEND_COMMAND ioctl supported by the Linux SCSI mid level. The
version 3 sg driver also added the SG_IO ioctl that is synchronous (i.e. it
issues the requested SCSI command and waits for the response (or a timeout)
before the ioctl returns to the user space program that invoked it). The
SG_IO ioctl is now supported in other parts of the Linux kernel in the 2.6
series.

In sg3_utils version 1.27 support has been added for the Linux bsg driver
which use the sg version 4 interface. There seems no point in renaming
this package sg4_utils. The existing utilities just silently support either.
Cuurently the source build must be able to see the /usr/include/linux/bsg.h
file. Then at run time the /proc/devices pseudo file needs to have an entry
for the bsg driver (appeared around lk 2.6.28). With this in place each
utility at run time checks the device it has been given and if it is a char
device whose major number matches the bsg entry in /proc/devices then the
sg v4 interface is used. Otherwise the sg v3 interface is used.

Utilities that wish to use the asynchronous SCSI command interface (i.e. via
a write() read() sequence) or issue special "commands" (e.g. bus and device
resets) still need to use the Linux sg driver. Note that various
drivers (e.g. cdrom/sr) have different open() flag and permissions policies
that the user may need to take into account.

If you have problems or questions about them please contact the author.
Documentation for the Linux sg device driver can be found at:
http://sg.danny.cz/sg/p/sg_v3_ho.html . This is written in DocBook and the
original xml can be found in the same directory with the ".xml" extension.
Postscript and pdf renderings are also in that directory. Older documentation
for the sg version 3 driver can be found at:
http://sg.danny.cz/sg/p/scsi_generic_v3.txt .

All utilities are either "GPL"-ed or have a FreeBSD license. The author's
intention is that users may incorporate all or part of the code in their work
as they please. Attribution is encouraged. Please check the code as other
contributors (apart from the author) may also have copyright notices. For a
list of contributors see the CREDITS file.

The include/sg_lib_data.h and lib/sg_lib_data.c files contain ASCII text
corresponding to most of the SCSI commands, errors and warning conditions.
The interface to this data plus several related helper functions are found
x in the include/sg_lib.h and lib/sg_lib.c files. The include/sg_cmds_basic.h
and lib/sg_cmds_basic.c" files contains code to invoke common SCSI commands
and associated response processing. The include/sg_cmds_mmc.h and
lib/sg_cmds_mmc.c files contain code to invoke SCSI commands specific to MMC
(for cd/dvd/bd devices). The include/sg_cmds_extra.h and lib/sg_cmds_extra.c
files contains code to invoke lesser used SCSI commands and associated
response processing. All are guided by recent drafts at www.t10.org which
is the home site of SCSI (draft) standards. Linux specific code has been
removed from above mentioned files. The SCSI command implementations
in lib/sg_cmds_basic.c, lib/sg_cmds_mmc.c and lib/sg_cmds_extra.c access the
OS pass-through mechanism via the function based interface defined in
include/sg_pt.h . The Linux specific implementation of that pass through is
found in the lib/sg_pt_linux.c file. Since almost all of the utilities use
these files, a shared library called "libsgutils<num>.so" is built. Use of
this library cuts down the size of binary distributions of sg3_utils
significantly. The build scripts provided in the lib subdirectory builds
libsgutils<num>.so The rest of the source code files have been relocated to
the src subdirectory.  See the INSTALL file for more information.

All the utilities in the src subdirectory have "man" pages that are
placed in the doc subdirectory. There is also a sg3_utils (8) man page that
summarizes common facilities including exit statuses. Additional
information (including each utility's version number) can be found towards
the top of each ".c" file corresponding to the utility name.

The sg driver in Linux can be seen as having 3 distinct versions:

   v1   lk < 2.2.6     sg_header based relatively unchanged since 1992
   v2   lk >= 2.2.6    enhanced sg_header interface structure [1999/4/16]
   v3   lk >= 2.4      additional sg_io_hdr interface structure [2001/1/4]
   v3   lk >= 2.6      same interface as found in lk 2.4 [2.6.0: 2003/12/18]

and the bsg driver supports the sg v4 interface and was added around 
lk 2.6.28 . This package is targeted at "v3" and "v4". Another package called
"sg_utils" is targeted at "v2" and to a lesser extent "v1". The "sg_utils"
package has a subset of the utilities found in this package.

In Linux some sg driver ioctls (notably SG_IO) are defined for many block
devices in lk 2.6 series. In practice this means all SCSI block devices,
ATAPI block devices (mainly CD, DVD and BD optical devices) but _not_ ATA
disks, depending on which kernel configuration options, can be accessed by
the utilities in this package. SATA disks that use the libata kernel library
(or some other SCSI to ATA Translation (SAT) Layer (SATL)) accept SCSI
commands and thus are supported. Support for the SG_IO as been added to the
scsi tape driver (st) in lk 2.6.6 .

In the src directory the bulk of the utilities are written in relatively
clean POSIX compliant C code with Linux specific system calls and structures
removed and placed in linux specific files in the lib directory. A small
number of utilities in the src directory do contain Linux specific logic
and are not ported to other OSes (e.g. sg_dd). One utility, sg_scan, has
two separate implementations, one for Linux (sg_scan.c.linux) and one for
Windows (sg_scan.c.win32). The src-lib directory split approach allows
FreeBSD, Solaris, Tru64 and Windows specific code to be isolated to a few
files in the lib directory whose interfaces match those of the Linux
specific code.

Darwin is not supported because the Apple folks do not want to give their
users a pass-through SCSI interface. The author has read about creative
hackers using a VM containing a real OS to circumvent the Apple restriction.

Building
========
This package is designed to be built with the usual:
    "./configure ; make ; make install"
sequence. In some situations that may need to be prefixed by a call to
the "./autogen.sh" script which invokes autoconf and automake. That in turn
may require packages containing those utilities to be installed. The
libtool utility is also required. Naturally a C compiler is required
and due to the vagaries of libtool a C++ compiler also.

The C code in this package is written for portability rather than speed.
It assumes a level of C99 compliance and favours POSIX system and library
calls over OS specific calls.

More generic build information can be found in the INSTALL file.

In Linux there are package build files for "rpm" based and for "deb" based
systems. The 'sg3_utils.spec' file in the main directory can be used like
this: 'rpmbuild -ba sg3_utils.spec' in a rpmbuild tree SPECS directory.

The 'build_debian.sh' script should build several "deb" packages and place
them in the parent directory. In debian based systems doing
a 'apt-get install build-essential' is one way to get most of build
environment needed if it has not already been loaded. There are now some
problems with this script and the superseded Debian 4.0 ("etch"). See
debian/README.debian4 for a workaround.

Warning
=======
Many devices use SCSI command sets over transport protocols not normally
associated with SCSI (as defined at http://www.t10.org ). Some of these
devices react poorly (e.g. lock up) when sent SCSI commands that they don't
support. Even sending a supported SCSI command with a field set to an
unexpected value can cause problems. [The author is talking about billions
of USB devices with horrible SCSI implementations.]

For example, all "SCSI" devices must support the INQUIRY command which the
SCSI-2 standard says should request a 36 byte response. However later SCSI
standards (e.g. SPC-2) have increased that length but some SCSI devices lock
up when they receive a request for anything other than a 36 byte response.

Any well implemented "SCSI" device should react sensibly when a utility in
sg3_utils sends a SCSI command that it doesn't support. Unfortunately this
cannot be guaranteed.


Utilities
=========
Here is list in alphabetical order of utilities found in the 'src'
subdirectory of the sg3_utils package:
  - sginfo, sgm_dd, sgp_dd, sg_dd, sg_emc_trespass, sg_get_config,
    sg_get_lba_status, sg_format, sg_ident, sg_inq, sg_logs, sg_luns, sg_map,
    sg_map26, sg_modes, sg_opcodes, sg_persist, sg_prevent, sg_raw, sg_rbuf,
    sg_rdac, sg_read, sg_readcap, sg_read_block_limits, sg_read_buffer,
    sg_read_long, sg_reassign, sg_request, sg_reset, sg_rmsn, sg_rtpg,
    sg_safte, sg_sat_identify, sg_sat_phy_event, sg_sat_set_features,
    sg_scan, sg_senddiag, sg_ses, sg_start, sg_stpg, sg_sync, sg_test_rwbuff,
    sg_turs, sg_unmap, sg_verify, sg_vpd, sg_write_buffer, sg_write_long,
    sg_write_same, sg_wr_mode

Each of the above utilities depends on header files found in the 'include'
subdirectory and library code found in the 'lib' subdirectory. Associated
man pages are found in the 'doc' subdirectory. Additional programs found
in the 'archive', 'examples' and 'utils' subdirectories in not build by the
top level build infrastructure. Linux binary distributions of the sg3_utils
package (e.g. "rpm" and debian packages) typically contain the shared
library, the utilities found in the 'src' subdirectory, their associated man
pages and some documentation files (e.g. README, INSTALL, CREDITS, COPYING
and COVERAGE). See the INSTALL file for instructions about building and
installing from a source "tarball".

Man pages can be read (without building and installing the package) by
going to the 'doc' subdirectory and executing something like this:
 $ man ./sg_dd.8

To see which SCSI commands (and ATA commands) are used by these utilities
refer to the COVERAGE file.

Here is a list in alphabetical order of utilities found in the 'archive'
subdirectory:
  - isosize, scsi_devfs_scan, sg_debug, sgq_dd
Some of these utilities have man pages.

Here is a list in alphabetical order of utilities found in the 'examples'
subdirectory:
  - bsg_queue_tst, sg_excl, scsi_inquiry, sg_iovec_tst, sg_queue_tst,
    sg_sat_chk_power, sg__sat_identify, sg__sat_phy_event,
    sg__sat_set_features, sg_sat_smart_rd_data, sg_simple1, sg_simple2,
    sg_simple3, sg_simple4, sg_simple5 and sg_simple16

Also in that subdirectory is a script to test sg_persist, an example data
file for sg_persist (called "transport_ids.txt") and an example data file for
sg_reassign (called "reassign_addr.txt"). There are several scripts
for 'sg_senddiag -pf -raw=-' that will put some SAS disk phys into
a "compliant jitter tolerance pattern" (CJTPAT). 

The 'utils' subdirectory contains source and a Makefile to build "hxascdmp"
which accepts binary data from stdin (or a file on the command line) and
outputs an ASCII-HEX and ASCII representation of it. It is similar to the
Unix od command. There is also code to sg_chk_asc.c which checks a given
text file (typically a copy of http://www.t10.org/lists/asc-num.txt ) and
checks it against the asc/ascq text strings held in sg_lib_data.c .

The 'doc' subdirectory contains a README file containing the urls of
various related documents.

The 'scripts' subdirectory contains some bourne (bash) shell scripts that
rely on utilities in the main directory. One script uses the sdparm utility.
These scripts are described in the scripts/README file and have usage
messages.
    

Notes for utilities without man pages
=====================================
These utils are found in the 'examples' subdirectory.

The "scsi_inquiry" program shows the use of the SCSI_IOCTL_SEND_COMMAND
ioctl to send a SCSI INQUIRY command. That ioctl() is supported by the 
SCSI sub system mid level and so is common to all sd, sr, st and sg devices. 
That ioctl is deprecated in the lk 2.6 series. This program has been placed
in the "examples" subdirectory.

"sgq_dd" is yet another variant of dd found in the archive directory.
From the user's point of view it is very similar to sgp_dd but uses a
non-blocking state machine rather then POSIX threads for parallelism.

"sg_debug" is effectively defunct now. The user can instead execute:
'cat /proc/scsi/sg/debug' . This command has been placed in the archive
directory.

"sg_simple1" and "sg_simple2" are example programs demonstrating calls
to the SCSI INQUIRY and TEST UNIT READY commands. They only differ in their
error processing: sg_simple1 uses sg_lib.[hc] for error processing while
sg_simple2 does its own more primitive checks.

"sg_simple3" tests out user space scatter gather added to the version 3
sg driver.

"sg_simple4" shows the INQUIRY command using mmap-ed IO to obtain its
response buffer.

"sg_simple5" also sends and INQUIRY and TEST UNIT READY commands. It
uses the generic pass through mechanism based on sg_pt.h . It will
currently build in Linux and FreeBSD (with "make -f Makefile.freebsd").
It has extensive error checking code.

"sg_simple16" attempts to send a 16 byte SCSI command, READ_16, to the
scsi device. This is only supported for lk >= 2.4.15 and for adapter
drivers that indicate that they have 16 byte CDB capability (otherwise
DID_ABORT will appear in the host_status).

"sg_sat_chk_power" attempts to push an ATA CHECK POWER MODE command
through the SAT-defined ATA PASS_THROUGH (16) SCSI command. That
ATA command needs to read the "FIS" registers after the command is
completed which involves using the ATA Status Return (sense data)
descriptor (as defined in SAT).

"sg_sat_smart_rd_data" attempts to push an ATA SMART/READ DATA command
through the SAT-defined ATA PASS_THROUGH (16) SCSI command. If
successful, the 256 word (512 byte) response is output.


Command line processing
=======================
These utilities can be divided into 3 groups when their handling of command
line arguments is considered:
  - ad hoc, typically in a short form only, sometimes longer (e.g.
    "sg_logs -pcb /dev/sdc")
  - inspired by the dd Unix command (e.g. sg_dd, sgm_dd, sgp_dd, sg_read)
  - recent utilities use "getopt_long" (see "man getopt_long")
    type command lines. These have short form (starting with "-")
    and corresponding longer form (starting with "--") options.

The older utilities that use ad hoc options, in alphabetical order:
  - sg_emc_trespass, sginfo(1/2), sg_inq, sg_logs, sg_map, sg_modes,
    sg_opcodes, sg_rbuf, sg_rdac, sg_readcap, sg_reset, sg_scan (Linux),
    sg_senddiag, sg_start, sg_test_rwbuf, sg_turs
In sg3_utils version 1.23 the following utilities from this group were
converted to have a dual getopt_long/ad_hoc interface, defaulting to
the getop_long interface:
  - sg_inq, sg_logs, sg_modes, sg_opcodes, sg_rbuf, sg_readcap,
    sg_senddiag, sg_start, sg_turs
These can be switched back to the older (backward compatible) ad hoc
interface by defining the SG3_UTILS_OLD_OPTS environment variable
or using '-O' as the first command line option.

The more recent utilities that use "getopt_long" only are:
  - sg_format sg_get_config sg_get_lba_status sg_ident sg_luns sg_map26
    sg_persist sg_prevent sg_raw sg_read_block_limits sg_read_buffer
    sg_read_long sg_reassign sg_requests sg_rmsn sg_rtpg sg_safte
    sg_sat_identify sg_sat_phy_event sg_sat_set_features sg_scan(w) sg_ses
    sg_stpg sg_sync sg_test_rwbuf sg_unmap sg_verify sg_vpd sg_write_buffer
    sg_write_long sg_write_same sg_wr_mode


Dangerous code
==============
This code:
    unsigned char uc = 0x80;
    unsigned long long = ull;
    ull = (uc << 24);
Gives an unexpected result because the 'unary conversion' of uc to a (32 bit
signed) 'int' before the shift. The resultant type from the shift is also
an int and it has its top bit set so there is sign extension when it is
assigned into a 64 bit integer. The above will fail in a similar way on 64
bit architectures that use the LP64 data model, if 'unsigned long ul' is used
instead of ull variable in the above code example.

Other SCSI and storage tools
============================
See http://sg.danny.cz/sg/tools.html


Doug Gilbert
31st March 2010
