This message is from the T13 list server.
Mark
That was all back in the early to mid 90s. Do you believe that it
is relevant for systems today?
-------------------------------------------------
Curtis E. Stevens
20511 Lake Forest Drive #C-214D
Lake Forest, California 92630
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: [EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Evans,
Mark
Sent: Thursday, April 06, 2006 7:20 AM
To: Elliott, Robert (Server Storage); [email protected]
Subject: RE: [t13] ATA8-ACS NOP proposals
This message is from the T13 list server.
Hi Rob,
I was reviewing your proposal (e06126r0) and have a serious issue (I won't
go into the editorial issues I have with the proposal here). In the
overview of your proposal you write, "However, since NOP with subcommand 00h
returns the same result as an unsupported opcode, it doesn't matter if it is
'supported' or not." This isn't all NOP does. It DOES matter whether a
device reports that the command is supported or not. You have to go back to
what NOP was originally intended to do. The last place this is hinted at is
in the description of NOP in ATA/ATAPI-4 rev 16, "This command enables a
host, that only performs 16-bit register accesses, to check device status."
It seems that Pete McLean removed this when he added in Tony Goodfellow's
proposal for NOP auto poll (d97142r1) during A/A-4 letter ballot resolution.
If you go back farther to earlier standards, you'll see that "...when a host
performing 16-bit register accesses writes to the Drive Head Register, one
byte contains the Command Register, so the drive sees a new command when the
intended purpose is only to select a drive. Both drives may be Busy but not
necessarily Ready i.e., Drive 0 may be ready, but not drive 1."
So, there is a unique meaning to saying that a device supports NOP just as
it is. This meaning can't be muddied by adding additional requirements. If
you want additional requirements, you'll have to find a new bit in IDENTIFY
DEVICE data.
Regards,
Mark Evans
Maxtor Corporation
500 McCarthy Boulevard
Milpitas, CA 95035
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elliott,
Robert (Server Storage)
Sent: Monday, April 03, 2006 11:37 AM
To: [email protected]
Subject: [t13] ATA8-ACS NOP proposals
This message is from the T13 list server.
Stemming from some SCSI to ATA Translation (SAT) letter ballot discussions
on the behavior of the NOP command, I've prepared two proposals for T13 to
discuss at the April meeting (posted on
http://www.t13.org):
e06125r0-ATA8-ACS_IDENTIFY_PACKET_DEVICE_supported_features.pdf
IDENTIFY PACKET DEVICE must return specific values for feature sets/commands
that are mandatory or prohibited in packet devices (e.g.
NOP is mandatory).
e06126r0-ATA8-ACS_NOP_clarifications.pdf
Since NOP with subcommand 00h behaves the same as an unsupported command,
there is no reason for IDENTIFY DEVICE to include NOP Supported/Enabled bits
except for subcommands 01h-FFh. Those subcommands have different behavior
for devices supporting the Overlapped and Queued feature sets. So, this
proposal adds a sentence noting that, for devices supporting the Overlapped
feature set, the IDENTIFY DEVICE data bits indicating NOP support also imply
that NOP subcommands 01h-FFh are supported.
Also, the NOP Auto Poll model discusses how host adapters might complete the
command with ERR=0, which the NOP command description doesn't mention at
all. Based on d97142r1, the proposal that added the feature, changes are
suggested to mention this exception in the NOP command description.
--
Rob Elliott, [EMAIL PROTECTED]
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott
