Hi,
Maybe this is a stupid question.
I have deemed that, SCSI commands can be transferred in a “CDB” struct. Now in Microsoft Windows, SCSI commands are transferred in a “SCSI_REQUEST_BLOCK” struct, and “CDB” becomes its member.
So are there many redundant variables(such as UCHAR PathId; UCHAR TargetId; UCHAR Lun;PVOID SenseInfoBuffer; ) in struct
“SCSI_REQUEST_BLOCK” ?
Nothing redundant.
In SCSI, each command can have the associated data buffer, and can return
sense info if fails with CHECK CONDITION. Yes, the command itself is a CDB,
but, to execute it, also the data buffer is needed and the sense info buffer is
needed. Also, you need a space to store the SCSI protocol’s status value -
GOOD/CHECK CONDITION etc.
SRB is a bunch of all of this, with some fields added for storage port
convinience like the ->OriginalRequest.
Path/Target/Lun field are mostly obsolete in the modern PnP world above the
storage port and auto-filled by the storage port. But, for miniport/HBA driver,
they are important - they say it how to select the target for the command.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Hi,
> Maybe this is a stupid question.
> I have deemed that, SCSI commands can be transferred in a “CDB” struct. Now
in Microsoft Windows, SCSI commands are transferred in a “SCSI_REQUEST_BLOCK”
struct, and “CDB” becomes its member.
> So are there many redundant variables(such as UCHAR PathId; UCHAR
TargetId; UCHAR Lun;PVOID SenseInfoBuffer; ) in struct
> “SCSI_REQUEST_BLOCK” ?
>
>
And one of the most important parameters is Srb->DataTransferLength and
CDB->AllocationLength. A comparison of these for a DataIN will determine:
a) buffer overrun (residual overrun) where the Srb->DataTransferLength <
CDB->AllocationLength (receive buffer is too small, you can check the
CDB->AllocationLength for how large your buffer needs to be)
b) buffer underrun (residual underrun) where the Srb->DataTransferLength
> CDB->AllocationLength (receive buffer is too large)
Unfortunately both have the same NTSTATUS STATUS_DATA_OVERRUN or
STATUS_BUFFER_OVERFLOW, never figured out why this is the case.
~kenny
Maxim S. Shatskih wrote:
Nothing redundant.
In SCSI, each command can have the associated data buffer, and can return
sense info if fails with CHECK CONDITION. Yes, the command itself is a CDB,
but, to execute it, also the data buffer is needed and the sense info buffer is
needed. Also, you need a space to store the SCSI protocol’s status value -
GOOD/CHECK CONDITION etc.SRB is a bunch of all of this, with some fields added for storage port
convinience like the ->OriginalRequest.Path/Target/Lun field are mostly obsolete in the modern PnP world above the
storage port and auto-filled by the storage port. But, for miniport/HBA driver,
they are important - they say it how to select the target for the command.
Why do you say things like SenseInfoBuffer are ‘redundant’?
The CDB contains no pointers. It contains no address information. It only contains parameters that the disk will understand.
The SRB contains information that the drivers processing the request need, such as the address of the LUN the command is directed to, the location to store sense info data if there’s an error, etc…
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of zoranzi021@163.com
Sent: Tuesday, March 11, 2008 2:22 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] SCSI_REQUEST_BLOCK and CDB?
Hi,
Maybe this is a stupid question.
I have deemed that, SCSI commands can be transferred in a “CDB” struct. Now in Microsoft Windows, SCSI commands are transferred in a “SCSI_REQUEST_BLOCK” struct, and “CDB” becomes its member.
So are there many redundant variables(such as UCHAR PathId; UCHAR TargetId; UCHAR Lun;PVOID SenseInfoBuffer; ) in struct
“SCSI_REQUEST_BLOCK” ?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
But the following IP link shows that the infomation “LUN” is already in CDB structure: http://en.wikipedia.org/wiki/SCSI_Read_Commands
OK, this has already been stated but, here goes again. The CDB structure
is sent all the way to the target. The exact structure that is defined
and created is sent. The SRB is is interpreted by the miniport to
determine where the CDB should be sent. The SRB contains additional
information that can be used in combination with the CDB to determine
the validity of the response.
Do you have a specific questions, as opposed to pointing out links to wiki?
- build a CDB
- build an IRP using SCSI_PASS_THROUGH, which builds an SRB at
IRP->Parameters.Scsi.Srb
You must have the memory allocated for the response on a data in, or the
data to send on a data out, without an SRB how do you propose you should
send this information to the miniport?
I’m not sure why there is redundant information, except for
optimizations, why should the miniport decode a CDB if it already has to
decode an SRB? Also, for Vendor Specific CDB, i.e. Cx OPCodes, how is
the miniport suposed to interpret this structure?
There are many many links and books on SCSI/FCP/iSCSI …
~kenny
zoranzi021@163.com wrote:
But the following IP link shows that the infomation “LUN” is already in CDB structure: http://en.wikipedia.org/wiki/SCSI_Read_Commands
xxxxx@163.com wrote:
But the following IP link shows that the infomation “LUN” is already in CDB
structure: http://en.wikipedia.org/wiki/SCSI_Read_Commands
Only READ6 and READ10 have LUN info (I also doubt all apps will set it). If we don’t have SCSI_REQUEST_BLOCK, how can drivers get it?
I read your replies and then read “SCSI Primary Commands - 4” document.
Now I draw this conclusion as the following:
CDB structure has these common fields: operation code, service action, logical block address, transfer length, etc., …
sense data has a predefined format, but sense data is not contained in CDB structure.
At 05:58 12/03/2008, zoranzi021@163.com wrote:
I read your replies and then read “SCSI Primary Commands - 4” document.
Now I draw this conclusion as the following:
CDB structure has these common fields: operation code, service
action, logical block address, transfer length, etc., …
sense data has a predefined format, but sense data is not contained
in CDB structure.
Still wondering what your point is ?
The SRB structure was probably one of the first round of structures
created by the NT design team as part of the prototyping phase back
in the early 90’s.
Never mind SPC-4, the original NT was designed around SCSI-1. Try
going back and seeing what a mess that was, especially with some of
the device implementations. From first release the original SCSI
miniport ended up nearly doubling in size to cope with specific bad
device implementations. The SRB is simply a wrapper to efficiently
pass the CDB from one layer to the next. Where there is some field
duplication with the CDB, one of the other reasons apart from
efficiency was because in the early SCSI days the design team came
across devices that made nasty assumptions about their environment
and decided they didn’t need to fill that information in to the CDB
in order to work.
Today one could argue that devices are a lot better and SCSI is far
more mature but changing the SRB because you don’t like it would
break a hell of a lot of code.
Mark.
The Wiki article is wrong. Ever since SCSI-2 the LUN field in the CDB is
obsolete and should not be filled in. It is now a reserved field, even
for READ6 and READ10.
(NT4 class drivers filled it in, but ever since, it has been left zero.)
The only other thing that MIGHT be considered redundant between the CDB
and the SRB would be the DataTransferLength, which is always specified in
bytes. It is not REALLY redundant. The miniport driver uses this to
determine how to set up the data transfer. Sure, lots of CDBs have a
length field in them or have an implied data length, but the miniport
would have to decode the CDB, and this is problematic because it would
have to know the block size on the device for reads and writes, and then
there are vendor-unique commands.
If you think there is anything else redundant between the CDB and the SRB,
let us know.
Jerry.
zoranzi021@163.com
Sent by: xxxxx@lists.osr.com
03/11/2008 11:52 PM
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
RE:[ntdev] SCSI_REQUEST_BLOCK and CDB?
But the following IP link shows that the infomation “LUN” is already in
CDB structure: http://en.wikipedia.org/wiki/SCSI_Read_Commands
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Ok, minor correction. Here is what SCSI-2 says about the LUN field.
6.2.2 Logical Unit Number
The logical unit number is defined in the IDENTIFY message (5.6.7). The
target shall ignore the logical unit number specified within the command
descriptor block if an IDENTIFY message was received. It is recommended
that
the logical unit number in the command descriptor block be set to zero.
NOTICE: The logical unit number field is included in the command
descriptor block for compatibility with some SCSI-1 devices. This
field
may be reclaimed in SCSI-3. New implementations should use the
outbound
IDENTIFY message, which is mandatory in SCSI-2, to establish the I_T_L
nexus.
The date on the SCSI-2 specification is 1991.
SCSI-3 did in fact change all LUN fields in CDBs to Reserved.
Jerry.
xxxxx@attotech.com
Sent by: xxxxx@lists.osr.com
03/12/2008 08:27 AM
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
RE:[ntdev] SCSI_REQUEST_BLOCK and CDB?
The Wiki article is wrong. Ever since SCSI-2 the LUN field in the CDB is
obsolete and should not be filled in. It is now a reserved field, even
for READ6 and READ10.
(NT4 class drivers filled it in, but ever since, it has been left zero.)
The only other thing that MIGHT be considered redundant between the CDB
and the SRB would be the DataTransferLength, which is always specified in
bytes. It is not REALLY redundant. The miniport driver uses this to
determine how to set up the data transfer. Sure, lots of CDBs have a
length field in them or have an implied data length, but the miniport
would have to decode the CDB, and this is problematic because it would
have to know the block size on the device for reads and writes, and then
there are vendor-unique commands.
If you think there is anything else redundant between the CDB and the SRB,
let us know.
Jerry.
zoranzi021@163.com
Sent by: xxxxx@lists.osr.com
03/11/2008 11:52 PM
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
RE:[ntdev] SCSI_REQUEST_BLOCK and CDB?
But the following IP link shows that the infomation “LUN” is already in
CDB structure: http://en.wikipedia.org/wiki/SCSI_Read_Commands
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Yes, I now think there is no redundant variable member of SCSI_REQUEST_BLOCK. I mean since sense data is not the member of CDB, so no strange that it is SRB. Thank all.
> I’m not sure why there is redundant information,
There is no redundant information. What particular SRB field do you consider
redundant?
optimizations, why should the miniport decode a CDB if it already has to
decode an SRB?
CDB is part of SRB, not an alternative for SRB.
Let’s compare this to natural language grammar. SRB is “sentence”, while CDB is
“predicate”. Predicate is only a part of the sentence.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Only READ6 and READ10 have LUN info (I also doubt all apps will set it).
LUN info in the CDB was obsolete even in year 2000.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> The only other thing that MIGHT be considered redundant between the CDB
and the SRB would be the DataTransferLength, which is always specified in
bytes. It is not REALLY redundant. The miniport driver uses this to
determine how to set up the data transfer. Sure, lots of CDBs have a
length field in them or have an implied data length, but the miniport
would have to decode the CDB
The miniport should not decode the length from the CDB, it should
use ->DataTransferLength instead.
->DataTransferLength is the caller’s buffer length for the miniport software
and for the HBA hardware.
The CDB length’s only purpose is to provide the LUN with the length limit.
This length should only be sent to a LUN (with the whole CDB).
It is OK if CdbLength is < ->DataTransferLength, not OK otherwise (it will
create an overrun error on a miniport/HBA level).
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Comments inline in red.
“Maxim S. Shatskih”
Sent by: xxxxx@lists.osr.com
03/13/2008 08:14 AM
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
Re:[ntdev] RE:SCSI_REQUEST_BLOCK and CDB?
> The only other thing that MIGHT be considered redundant between the CDB
> and the SRB would be the DataTransferLength, which is always specified
in
> bytes. It is not REALLY redundant. The miniport driver uses this to
> determine how to set up the data transfer. Sure, lots of CDBs have a
> length field in them or have an implied data length, but the miniport
> would have to decode the CDB
This is not the complete text of that paragraph from the original message.
How about “…, and this is problematic because it would have to know the
block size on the device for reads and writes, and then there are
vendor-unique commands.”
The miniport should not decode the length from the CDB, it should
use ->DataTransferLength instead.
That was the whole point. It would be pretty much impossible for the
miniport to universally and accurately decode any arbitrary CDB to
determine the data transfer length with the information it has at hand.
(Also, of course, it would then be “trusting” that the caller allocated
the correct size buffer.) In absolutely no way was I suggesting that
anybody decode the length from the CDB!
->DataTransferLength is the caller’s buffer length for the miniport
software
and for the HBA hardware.
The CDB length’s only purpose is to provide the LUN with the length
limit.
This length should only be sent to a LUN (with the whole CDB).
It is OK if CdbLength is < ->DataTransferLength, not OK otherwise (it will
create an overrun error on a miniport/HBA level).
“OK” is a bit misleading. If the CDB’s implied length is <
DataTransferLength, or the LUN otherwise returns less data than
DataTransferLength, the driver returns SRB_STATUS_DATA_OVERRUN and it
corrects the DataTransferLength in the SRB to be the actual number of
bytes transferred. Oh, and be careful of that “CdbLength” thing - there
is a CdbLength in the SRB.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> “OK” is a bit misleading. If the CDB’s implied length is <
DataTransferLength, or the LUN otherwise returns less data than
DataTransferLength, the driver returns SRB_STATUS_DATA_OVERRUN and it
corrects the DataTransferLength in the SRB to be the actual number of
bytes transferred.
I remember lots of MMC SCSI commands which return some structure arrays of the
size not known apriori, so the returned data length is always < CdbLength and <
DataTransferLength.
I never ever saw SRB_STATUS_DATA_OVERRUN with this.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
From the WDK docs for SCSI_REQUEST_BLOCK, SrbStatus:
SRB_STATUS_DATA_OVERRUN
Indicates that a data overrun or underrun error occurred. The miniport
driver also must update the SRB’s DataTransferLength member to indicate
how much data actually was transferred if an underrun occurs.
As an example, during the bus scan, when sending Inquiry commands for VPD
pages, Windows sets the DataTransferLength and the CDB’s AllocationLength
to 0xFF and always gets this status.
“Maxim S. Shatskih”
Sent by: xxxxx@lists.osr.com
03/13/2008 12:23 PM
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
Re:[ntdev] Re:RE:SCSI_REQUEST_BLOCK and CDB?
> “OK” is a bit misleading. If the CDB’s implied length is <
> DataTransferLength, or the LUN otherwise returns less data than
> DataTransferLength, the driver returns SRB_STATUS_DATA_OVERRUN and it
> corrects the DataTransferLength in the SRB to be the actual number of
> bytes transferred.
I remember lots of MMC SCSI commands which return some structure arrays of
the
size not known apriori, so the returned data length is always < CdbLength
and <
DataTransferLength.
I never ever saw SRB_STATUS_DATA_OVERRUN with this.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer