Hi
I are planning to use the SCSI vendor specific CDBs to introduce some
new commands. In this regard, I wanted to know how the size of the
vendor specific CDB needs to be specified as per the SCSI standards. I
find that the first 3 bits of the opcode denote the command group
which denotes the size of the CDB for standard commands. But I am not
sure how we would specify the size for groups 6 and 7 (vendor
specific) CDBs. Could someone please help me with this.
Pranava
<pranava.swarupa@gmail.com> wrote in message
news:1184000838.814241.320480@z28g2000prd.googlegr oups.com...
> Hi
> I are planning to use the SCSI vendor specific CDBs to introduce some
> new commands. In this regard, I wanted to know how the size of the
> vendor specific CDB needs to be specified as per the SCSI standards. I
> find that the first 3 bits of the opcode denote the command group
> which denotes the size of the CDB for standard commands. But I am not
> sure how we would specify the size for groups 6 and 7 (vendor
> specific) CDBs. Could someone please help me with this.
> Pranava
>
Since you are the vendor, you get to tell the size of the vendor unique
commands that you implement. It's usually good to stay within 12 bytes,
although 16 byte CDBs are showing up too. But be aware that you will break
many operating systems and drivers when you chose to use vendor unique
implementations. No fun explaining to end-users why your device causes hang
conditions, core dumps or blue screens...
If you can help it in any way, you probably want to stay clear from vendor
unique commands. It's better to implement vendor unique Mode Sense/Select
pages, or use Send Diagnostcs/Receive Diagnostics Result commands to trigger
special functions or to retrieve special data.
On Jul 9, 10:49 am, "Rob Turk" <wipe_this_r.t...@chello.nl> wrote:
> <pranava.swar...@gmail.com> wrote in message
>
> news:1184000838.814241.320480@z28g2000prd.googlegr oups.com...
>
> > Hi
> > I are planning to use the SCSI vendor specific CDBs to introduce some
> > new commands. In this regard, I wanted to know how the size of the
> > vendor specific CDB needs to be specified as per the SCSI standards. I
> > find that the first 3 bits of the opcode denote the command group
> > which denotes the size of the CDB for standard commands. But I am not
> > sure how we would specify the size for groups 6 and 7 (vendor
> > specific) CDBs. Could someone please help me with this.
> > Pranava
>
> Since you are the vendor, you get to tell the size of the vendor unique
> commands that you implement. It's usually good to stay within 12 bytes,
> although 16 byte CDBs are showing up too. But be aware that you will break
> many operating systems and drivers when you chose to use vendor unique
> implementations. No fun explaining to end-users why your device causes hang
> conditions, core dumps or blue screens...
>
> If you can help it in any way, you probably want to stay clear from vendor
> unique commands. It's better to implement vendor unique Mode Sense/Select
> pages, or use Send Diagnostcs/Receive Diagnostics Result commands to trigger
> special functions or to retrieve special data.
>
> Rob
Thanks very much Rob for your quick help. Its true that since I am the
vendor I can have my CDB of either 12 or 16 bytes. But for the SCSI
protocol to actually carry my CDB, I need to specify the CDB size
somewhere in the CDB itself. So i was wondering how I would specify
this.
Thanks
Pranava
"gopala" <gopala.surya@gmail.com> wrote in message
news:1184006607.423269.26150@d30g2000prg.googlegro ups.com...
> On Jul 9, 10:49 am, "Rob Turk" <wipe_this_r.t...@chello.nl> wrote:
>> Since you are the vendor, you get to tell the size of the vendor unique
>> commands that you implement. It's usually good to stay within 12 bytes,
>> although 16 byte CDBs are showing up too. But be aware that you will
>> break
>> many operating systems and drivers when you chose to use vendor unique
>> implementations. No fun explaining to end-users why your device causes
>> hang
>> conditions, core dumps or blue screens...
>>
>> If you can help it in any way, you probably want to stay clear from
>> vendor
>> unique commands. It's better to implement vendor unique Mode Sense/Select
>> pages, or use Send Diagnostcs/Receive Diagnostics Result commands to
>> trigger
>> special functions or to retrieve special data.
>>
>> Rob
>
> Thanks very much Rob for your quick help. Its true that since I am the
> vendor I can have my CDB of either 12 or 16 bytes. But for the SCSI
> protocol to actually carry my CDB, I need to specify the CDB size
> somewhere in the CDB itself. So i was wondering how I would specify
> this.
> Thanks
> Pranava
No, the CDB itself does not indicate it's size. If you look at Linux or
Windows SCSI passthrough code you can see that there's room for the CDB, a
separate byte to indicate the CDB length and a number of buffer pointers to
define where data cmes from or goes to. The defined groups have a
standardized length for each group, but the SCSI protocol itself can
basically support as many CDB bytes as you want. The SCSI protocol specifies
that as long as the target device stays in command phase, you can supply
additional command bytes. However, the HBA and device drivers between your
device and your custom application may put severe limits on what you will be
able to do.
Usually the size of the CDB is passed to the lower device driver by the
application. This is why vendor unique CDB's is usually not such a good
idea, as some device drivers make assumptions that may not be true for your
specific device. Even support for 16-byte CDB is not very common yet. If
your device is a common device that most operating systems have a common
driver for (Disk, CD/DVD, tape) then you may run into trouble because the
common driver may not allow you to send vendor unique commands. If it's
something special (processor device) then it's up to you to define the
entire driver chain.
If you are looking at developing some custom tools or diagnostics then you
may want to contact me off-list, I may be able to help a bit more. I'm sure
you will be able to un-mangle my e-mail address...
On Jul 9, 12:13 pm, "Rob Turk" <wipe_this_r.t...@chello.nl> wrote:
> "gopala" <gopala.su...@gmail.com> wrote in message
>
> news:1184006607.423269.26150@d30g2000prg.googlegro ups.com...
>
>
>
> > On Jul 9, 10:49 am, "Rob Turk" <wipe_this_r.t...@chello.nl> wrote:
> >> Since you are the vendor, you get to tell the size of the vendor unique
> >> commands that you implement. It's usually good to stay within 12 bytes,
> >> although 16 byte CDBs are showing up too. But be aware that you will
> >> break
> >> many operating systems and drivers when you chose to use vendor unique
> >> implementations. No fun explaining to end-users why your device causes
> >> hang
> >> conditions, core dumps or blue screens...
>
> >> If you can help it in any way, you probably want to stay clear from
> >> vendor
> >> unique commands. It's better to implement vendor unique Mode Sense/Select
> >> pages, or use Send Diagnostcs/Receive Diagnostics Result commands to
> >> trigger
> >> special functions or to retrieve special data.
>
> >> Rob
>
> > Thanks very much Rob for your quick help. Its true that since I am the
> > vendor I can have my CDB of either 12 or 16 bytes. But for the SCSI
> > protocol to actually carry my CDB, I need to specify the CDB size
> > somewhere in the CDB itself. So i was wondering how I would specify
> > this.
> > Thanks
> > Pranava
>
> No, the CDB itself does not indicate it's size. If you look at Linux or
> Windows SCSI passthrough code you can see that there's room for the CDB, a
> separate byte to indicate the CDB length and a number of buffer pointers to
> define where data cmes from or goes to. The defined groups have a
> standardized length for each group, but the SCSI protocol itself can
> basically support as many CDB bytes as you want. The SCSI protocol specifies
> that as long as the target device stays in command phase, you can supply
> additional command bytes. However, the HBA and device drivers between your
> device and your custom application may put severe limits on what you will be
> able to do.
>
> Usually the size of the CDB is passed to the lower device driver by the
> application. This is why vendor unique CDB's is usually not such a good
> idea, as some device drivers make assumptions that may not be true for your
> specific device. Even support for 16-byte CDB is not very common yet. If
> your device is a common device that most operating systems have a common
> driver for (Disk, CD/DVD, tape) then you may run into trouble because the
> common driver may not allow you to send vendor unique commands. If it's
> something special (processor device) then it's up to you to define the
> entire driver chain.
>
> If you are looking at developing some custom tools or diagnostics then you
> may want to contact me off-list, I may be able to help a bit more. I'm sure
> you will be able to un-mangle my e-mail address...
>
> Rob
Thanks so much Rob
I would investigate all this and get back to you if I have any further
questions
Thanks again
Rob Turk wrote:
>
> "gopala" wrote:
> >
> > [...]
> > Its true that since I am the
> > vendor I can have my CDB of either 12 or 16 bytes. But for the SCSI
> > protocol to actually carry my CDB, I need to specify the CDB size
> > somewhere in the CDB itself. So i was wondering how I would specify
> > this.
>
> No, the CDB itself does not indicate it's size. If you look at Linux or
> Windows SCSI passthrough code you can see that there's room for the CDB, a
> separate byte to indicate the CDB length and a number of buffer pointers to
> define where data cmes from or goes to. The defined groups have a
> standardized length for each group, but the SCSI protocol itself can
> basically support as many CDB bytes as you want. The SCSI protocol specifies
> that as long as the target device stays in command phase, you can supply
> additional command bytes.
SAM2 says:
| All SCSI transport protocol standards shall accept CDBs less than or
| equal to 16 bytes in length. CDBs using the format shown in table 19
| shall not exceed sixteen bytes in length.
[Table 19 shows the standard CDB with Opcode, Parameters and Control
byte]
So in theory every vendor command with group code 6 or 7 should work as
long as it is not longer than 16Bytes.
> However, the HBA and device drivers between your
> device and your custom application may put severe limits on what you will be
> able to do.
Have you some experience for which hardware/driver combinations it
doesn't work?
"Michael Baeuerle" <michael.baeuerle@stz-e.de> wrote in message
news:m10cm4-58i.ln1@micha.freeshell.org...
>
> SAM2 says:
> | All SCSI transport protocol standards shall accept CDBs less than or
> | equal to 16 bytes in length. CDBs using the format shown in table 19
> | shall not exceed sixteen bytes in length.
> [Table 19 shows the standard CDB with Opcode, Parameters and Control
> byte]
>
> So in theory every vendor command with group code 6 or 7 should work as
> long as it is not longer than 16Bytes.
>
Good info, thanks!
>> However, the HBA and device drivers between your
>> device and your custom application may put severe limits on what you will
>> be
>> able to do.
>
> Have you some experience for which hardware/driver combinations it
> doesn't work?
>
Not with vendor unique commands, but I've seen serveral instances where
having the wrong CDB length for defined groups in a descriptor would hang or
crash a system. DOS, Linux, Unix, Windows and Netware alike. There's been a
number of Dell OEM RAID controller/drivers I worked with on Netware which
were very unforgiving for non-disk related commands. SCO Unix isn't too
crazy about supplying invalid CDB lengths either. DOS ASPI drivers tolerated
specifying zero CDB length for a long time but at some point insisted on
valid length as well.
"Rob Turk" <wipe_this_r.turk@chello.nl> wrote in message news:cbJki.3987$%q4.386@amstwist00
> "Michael Baeuerle" <michael.baeuerle@stz-e.de> wrote in message news:m10cm4-58i.ln1@micha.freeshell.org...
> >
> > SAM2 says:
> > > All SCSI transport protocol standards shall accept CDBs less than or
> > > equal to 16 bytes in length. CDBs using the format shown in table 19
> > > shall not exceed sixteen bytes in length.
> > [Table 19 shows the standard CDB with Opcode, Parameters and Control
> > byte]
> >
> > So in theory every vendor command with group code 6 or 7 should work as
> > long as it is not longer than 16Bytes.
> >
> Good info, thanks!
Yes, perhaps the OP will be better off talking to Micha rather than to you, Rob.
He is even capable of setting his newsclient up properly, the simplicity of which
apparently goes beyond your capabilities.
>
> > > However, the HBA and device drivers between your
> > > device and your custom application may put severe limits on what you will
> > > be
> > > able to do.
> >
> > Have you some experience for which hardware/driver combinations it
> > doesn't work?
> >
>
> Not with vendor unique commands, but I've seen serveral instances where
> having the wrong CDB length for defined groups in a descriptor would hang or
> crash a system. DOS, Linux, Unix, Windows and Netware alike. There's been a
> number of Dell OEM RAID controller/drivers I worked with on Netware which
> were very unforgiving for non-disk related commands. SCO Unix isn't too
> crazy about supplying invalid CDB lengths either. DOS ASPI drivers tolerated
> specifying zero CDB length for a long time but at some point insisted on
> valid length as well.
>
> Rob
I know I'm just pandering to even post in regards to you, but I just
can't stand it any more. I haven't searched the forum archives or the
SCSI FAQ - who knows, maybe the answer to my question is in there
somewhere.
Here's my question:
"What is your problem?"
Do you like being perceived of as a total bore? Is it your goal that
the whole world of storage knows what an insufferable know-it-all with
no social skills you are?
It's a pity, you do seem to know a lot about storage but your manner
makes it all but impossible to listen to what you have to say.
Rob Turk is consistent in trying to provide help to people that come
here with questions - why do you feel the need to slam him in such a
childish manner at every opportunity?
Size of vendor specific CDBs 
Linear Mode
