This message is from the T13 list server.

> would be much better to provide the "ATA passthru" SCSI opcode that I 
> am planning to provide, as this will give everyone full access to the 
> ATA taskfile.

Yes.

I remember I saw the msc folk of usb.org once try to specify ATA pass
thru, then give up.

Difficult to define a usefully arbitrary and yet still concise and
efficient pass thru of ATA.

ATA in practice makes use of such vendor-specific extensions as reading
or writing while BSY:DRQ have unexpected values and distinguishing a
write from a rewrite or a read from a reread.  For example, before ATAPI
was standard, ATAPI was a vendor-specific extension.  Surviving that
level of creativity forces us to provide a completely transparent pass
thru, which by definition when applied to standard purposes requires
much detail that commonly does not change.

I've seen some people adopt the compromise of passing thru only the x200
bytes of op xEC/A1 Identify data, resorting to SCSI to express
everything else, and leaving everything else unavailable to anything but
a more direct connection.

> > That op x12 "INQUIRY" firmware revision field
> > is bytes x20..23 (32..35) ...
> > What follows at offset x24 (36) ...
> that is a "vendor reserved" field and I am the vendor.

Yes.

> However, I am unsure of the value, since anyone wishing to read the 
> entire firmware rev string by this method would have to write code that 
> works only on the Linux SCSI->ATA simulator, and nowhere else.

Yes and no.

I remember, working in SATAPI lately, I myself chose early to give
myself a way of sampling all op xEC/A1 Identify data, since the normal
Linux /proc/ide doesn't yet work there.

I'm guessing the people who do work like mine hereafter will feel the
same need.

Changing op x12 Inquiry to distinguish every different firmware does not
affects hosts that (for fear of not talking like Windows) sample only
the first x24 bytes of op x12 Inquiry data.

Fully distinguishing firmware helps developers on any host that can pass
thru requests for more of the data, but only when operated by people who
know the device under test in fact does fully distinguish firmware.

I'm thinking in our t10.org SCSI to ATA text we could encourage more
host vendors to adopt this good practice.  Simultaneously at t13.org we
could encourage more device vendors to adopt the good practice of fully
distinguishing firmware in the first four bytes.

Pat LaVarre


Reply via email to