aboutsummaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorDouglas Gilbert <dgilbert@interlog.com>2018-03-30 17:49:57 +0000
committerDouglas Gilbert <dgilbert@interlog.com>2018-03-30 17:49:57 +0000
commita66b91ad7e4878df47af0229b19d897bff3d47c8 (patch)
treecb376edc28d2dcb852aff6ead115c34e9d95c611 /README
parent382e35d67e18ba68f56c95b2a130d5467d2a2ccd (diff)
downloadsg3_utils-a66b91ad7e4878df47af0229b19d897bff3d47c8.tar.gz
sg_lib: add SG_LIB_LBA_OUT_OF_RANGE; sg_format: add --dry-run; sg_unmap: add --all=ST,RN[,LA] , --dry-run + --force
git-svn-id: https://svn.bingwo.ca/repos/sg3_utils/trunk@765 6180dd3e-e324-4e3e-922d-17de1ae2f315
Diffstat (limited to 'README')
-rw-r--r--README28
1 files changed, 21 insertions, 7 deletions
diff --git a/README b/README
index a6ed55cb..abaf17b3 100644
--- a/README
+++ b/README
@@ -178,7 +178,7 @@ future) that include MSVC being basically a C++ compiler, not a C/C++
compiler. For some reason MSVC only claims C89 compliance (i.e. the first
C standard from 1989). MSVC 2013 and 2015 are moving closer to C99
compliance and may be sufficient to compile this package. Another problem
-is the assumption of te availability of basic Unix system calls such as
+is the assumption of the availability of basic Unix system calls such as
open(). Nearly 20 years ago Microsoft indicated (promised ?) that it
would move in the direction of POSIX compliance, but very little ever
happened. "Talk is cheap, there should be a tax on it."
@@ -301,7 +301,7 @@ both C code (with the extension ".c") and C++ code (with the extension
".cpp"). There is a "Makefile" to build the C code and a "Makefile.cplus"
to build the C++ code. Both depend on some object files from the "lib"
subdirectory. So a sequence like this may be required prior to invoking
-one of the Mkaefiles in the directory: "cd <top_of_package> ;
+one of the Makefiles in the directory: "cd <top_of_package> ;
./configure ; cd lib ; make ; cd ../testing".
Here is a list in alphabetical order of utilities found in the 'testing'
@@ -483,14 +483,28 @@ and it has been replaced by:
The Linux kernel only supplies "unaligned" functions for 16, 32 and 64
bit quantities. SCSI commands also have cases of 24 and 48 bit numbers
so sg_unaligned.h contains support for those plus a variant where the
-bit length is passed as an argument.
-
-Associated with the above change fixed length integer types seem a better
+byte length is passed as an argument.
+
+The unaligned functions are inlined for speed (at the possible expense of
+space) and now have specializations depending whether the host is big or
+(more likely) little endian. These functions can be broken down to a
+memcpy() and optionally a byte-swap for 16, 32 and 64 bit operations.
+The memcpy() takes care of alignment while the byte-swap (bswap_16(),
+bswap_32() and bswap_64() ) addresses integer endianness. If the host is
+little endian and a little endian variant of the unaligned functions is
+requested, then no byte-swap is required. These specializations can be
+"compiled out" with this configure option: './configure
+--disable-fast-lebe' in which case the classic "C shifting" technique is
+used to implement all the unaligned functions.
+
+Associated with the above change, fixed length integer types seem a better
fit for SCSI command and parameter integers than the traditional integer
types in the C language. Fixed length integer types were standardized in
C99 and require the inclusion of <stdint.h>. For example this means for
an integer that will represent a 64 bit LBA, to favour using "uint64_t"
-over the "unsigned long long" type.
+over the "unsigned long long" type. Also "unsigned char" has mostly been
+replaced by "uint8_t" as the 8 bit (unsigned) byte type; "char" is still
+used for ASCII text.
Other SCSI and storage tools
@@ -499,4 +513,4 @@ See http://sg.danny.cz/sg/tools.html
Douglas Gilbert
-27th January 2018
+26th March 2018