forked from hreinecke/sg3_utils
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.win32
245 lines (215 loc) · 9.73 KB
/
README.win32
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
Introduction
============
The win32 port of sg3_utils contains those utilities that are _not_ specific
to Linux. One utility for listing available devices, sg_scan, has a
Windows-specific version for this port.
The dd variants from the sg3_utils package (e.g. sg_dd) rely on too many
Linux idiosyncrasies to be easily ported. A new package called 'ddpt'
contains a utility with similar functionality to sg_dd and is available
for Windows.
The Windows port uses the Microsoft SCSI Pass Through (SPT) interface.
It has two variants: "SPT" where data is double buffered; and "SPTD"
where data pointers to the user space are passed to the OS. Only Windows
2000 and later (i.e. not 95, 98 or ME) support SPT.
Two build environments are catered for: cygwin (see www.cygwin.com) and
MinGW ("Minimalist GNU for Windows", see www.mingw.org). Both are based in
the gcc compiler (although other C compilers should have little problem with
the source code). Cygwin is a more sophisticated, commercial product that
results in executables that depend on cygwin1.dll . No licensing is required
since sg3_utils is open source (with either BSD or GPL licenses) but users
will need to fetch that dll. On the other hand MinGW (and its companion MSYS
shell) builds freestanding console executables. The Unix library support is
not as advanced with MinGW which has led to some timing functions being
compiled out when sg3_utils is built for MinGW.
In later versions of Windows these utilities may need to be "run as
Administrator" for disks and other devices to be seen. If not those devices
will simply not be found as calls to query them fail with access permission
problems.
Supported Utilities
===================
Here is a list of utilities that have been ported:
sg_bg_ctl
sg_compare_and_write
sg_decode_sense
sg_format
sg_get_config
sg_get_lba_status
sg_ident
sg_inq [dropped ATA IDENTIFY DEVICE capability]
sg_logs
sg_luns
sg_modes
sg_opcodes
sg_persist
sg_prevent
sg_raw
sg_rdac
sg_read_attr
sg_read_block_limits
sg_read_buffer
sg_read_long
sg_readcap
sg_reassign
sg_referrals
sg_rep_zones
sg_requests
sg_reset_wp
sg_rmsn
sg_rtpg
sg_safte
sg_sanitize
sg_sat_identify
sg_sat_phy_event
sg_sat_read_gplog
sg_sat_set_features
sg_scan [this is Windows specific]
sg_seek
sg_senddiag
sg_ses
sg_ses_microcode
sg_start
sg_stpg
sg_stream_ctl
sg_sync
sg_timestamp
sg_turs
sg_unmap
sg_verify
sg_vpd
sg_wr_mode
sg_write_buffer
sg_write_long
sg_write_same
sg_write_verify
sg_write_x
sg_zone
Most utility names are indicative of the main SCSI command that they execute.
Some utilities are slightly higher level, for example sg_ses fetches SCSI
Enclosure Services (SES) status pages and can send control pages. Each
utility has a man page (placed in section 8). There is summary of the mapping
between utility names and the SCSI commands they execute in the COVERAGE
file. An overview of sg3_utils can be found at:
http://sg.danny.cz/sg/sg3_utils.html .
A copy of the "sg3_utils.html" file is in the "doc" subdirectory.
Some man pages have examples which use Linux device names which hopefully
will not confuse Windows users.
Two pass-through variants
=========================
The sg_pt_win32.c file uses the Windows SCSI Pass Through interface.
That is often shortened to SPT or SPTI. There are two DeviceIoControl()
ioctl variants provided: IOCTL_SCSI_PASS_THROUGH and
IOCTL_SCSI_PASS_THROUGH_DIRECT. The former involves double handling of
data (and perhaps an upper limit on the data length associated with
one SCSI command; MS documentation mentions 16 KB). The "direct"
variant passes a pointer from the user space and to be faster looks
and more versatile.
However the "direct" variant has potentially (unquantified) alignment
requirements and may not be (well) implemented by the hardware driver.
In practice some users have reported errors (e.g. 1117: a non-descript
IO error) when the direct variant is used.
Hence the non-direct variant is the default. The default size limit
on the data buffer is set at 16 KB but if the user asks for more
the data buffer will be extended. The OS or the hardware drivers
may reject the extended data buffer but we tried.
The package can be built using the direct variant with:
./configure --enable-win32-spt-direct
rather than:
./configure
prior to the 'make' call.
In sg3_utils version 1.31 run-time selection of the direct or indirect
interface was added with the scsi_pt_win32_direct(int state_direct)
function declared in sg_pt.h. The default is indirect unless
'./configure --enable-win32-spt-direct' was used in the build. If
'state_direct' is 1 then the direct interface is used and if it is 0
the indirect interface is used.
Both sg_read_buffer and sg_write_buffer can transfer buffers larger
than 16 KB. So in sg3_utils version 1.31, they use this new function
to set direct interface mode. This is regardless of whether or
not "--enable-win32-spt-direct" is given to ./configure .
Details
=======
Most of the ported utilities listed above use SCSI command functions
declared in sg_cmds_*.h headers . Those SCSI command functions are
implemented in the corresponding ".c" files. The ".c" files pass SCSI
commands to the host operating system via an interface declared in sg_pt.h .
There are currently five implementations of that interface depending on
the host operating system:
- sg_pt_linux.c
- sg_pt_freebsd.c
- sg_pt_osf1.c [Tru64]
- sg_pt_solaris.c
- sg_pt_win32.c
The ASPI32 interface which requires a dll from Adaptec is not supported.
The sg_scan utility is a special version for Windows and it attempts to show
the various available storage device names, one per line. Here is an example
of sg_scan's output:
# sg_scan
PD0 [C] FUJITSU MHY2160BH 0000
PD1 [DF] WD 2500BEV External 1.05 WD-WXE90
CDROM0 [E] MATSHITA DVD/CDRW UJDA775 CB03
Here is an example with added bus type:
# sg_scan -b
PD0 [C] <Ata > FUJITSU MHY2160BH 0000
PD1 [DF] <Usb > WD 2500BEV External 1.05 WD-WXE90
CDROM0 [E] <Atapi> MATSHITA DVD/CDRW UJDA775 CB03
Here is an example with added SCSI adapter scan:
# sg_scan -b -s
PD0 [C] <Ata > ST380011A 8.01
PD1 <Scsi > SEAGATE ST373455SS 2189
PD2 <Scsi > ATA ST3160812AS D
PD3 <Scsi > SEAGATE ST336754SS 0003
CDROM0 [F] <Atapi> HL-DT-ST DVDRAM GSA-4163B A103
TAPE0 <Scsi > SONY SDT-7000 0192
SCSI0:0,0,0 claimed=1 pdt=0h dubious ST380011 A 8.01
SCSI1:0,0,0 claimed=1 pdt=5h HL-DT-ST DVDRAM GSA-4163B A103
SCSI2:0,6,0 claimed=1 pdt=1h SONY SDT-7000 0192
SCSI5:0,17,0 claimed=1 pdt=0h SEAGATE ST373455SS 2189
SCSI5:0,19,0 claimed=1 pdt=0h ATA ST3160812AS D
SCSI5:0,21,0 claimed=1 pdt=0h SEAGATE ST336754SS 0003
SCSI5:0,112,0 claimed=0 pdt=10h LSI PSEUDO DEVICE 2.34
The storage devices scanned are PhysicalDrive<n> (shortened form PD<n> used),
CDROM<n> (which includes DVD and BD drives) and TAPE<n>. There is also an
optional SCSI adapter scan with device names of the form SCSI<n>:<b>:<t>:<l> .
These only come into play for devices that are not claimed by one of the
storage class drivers. The "LSI PSEUDO DEVICE" device above is an example
of an unclaimed device. The SCSI adapter scan does not show USB and IEEE
1394 connected devices.
Volume names (e.g. "C:") that match a storage device (or perhaps a
partition within that device) are shown in brackets. Notice there can be
zero, one or more volume names for each storage device. Up to four volume
names are listed in brackets, if there are more a "+" is added after the
fourth.
Several utilities have conditional compilation sections based on
the SG_LIB_MINGW define. For those who want to try native C compilers
on Windows setting the SG_LIB_MINGW define may help.
Build environments
==================
This package uses autotools infrastructure with the now common
"./configure ; make ; make install" sequence needed to build and install
from the source found in the tarball. Two Windows environments for building
Unix code are supported: cygwin and MinGW. If the "./configure" sequence
fails try using the ./autogen.sh prior to that sequence. The executables
produced are console applications that can be executed in either a cygwin,
MSYS or "cmd" shell. Various build options are available by giving
command line options to "./configure", see the INSTALL file for generic
information about the build infrastructure.
MinGW can be used to cross built on some Redhat (Linux) platforms. After
loading the cross build packages, the ./configure call in the normal
autotools sequence should be replaced by either mingw32-configure or
mingw64-configure. These scripts will set up the environment for
the cross build and then call ./configure (so this invocation should be
made in the top level of the untarred source). Options given to either
script (e.g. --enable-win32-spt-direct) will be passed through to
./configure .
Binary and Text files
=====================
A problem has been reported with binary output being written in a MinGW
environment (or executables build by MinGW). Windows has a concept of text
and binary files which is not found in Unix. Recent versions of MinGW
default to opening files in text mode. This can lead to binary output
(such as when the '--raw' option is given) having 0xa (i.e. LF) translated
to 0xd,0xa (i.e. CR,LF). sg3_utils version 1.26 attempts to fix this
problem by changing what it knows to be binary output files to "binary
mode" with the setmode() Windows command.
Douglas Gilbert
27th January 2018