Ralph Weber's CAM-2 Comments

Gary Porter garyp at ancot.com
Wed Feb 16 18:27:14 PST 1994


The following remarks address points brought up by Ralph Weber in his
comments (email with same subject). 
My comments are listed with Ralph's comment number, but no other
reference to the CAM-2 Document.

{017} It is a common practice in Target implementations to ask for 
the entire CDB (by handshaking with REQ assertions), even when BUSY.
I think the original wording is fine except for the name of the 
Status code. (BUSY, not BSY).

{019} The structure is the Command Descriptor Block (CDB).

{022} Linked commands have always been a problem for Targets. The
main source of the problem is that the Target doesn't even know a 
command is part of a linked sequence until the first CDB has been
interpreted. I see no way to specify ahead of time that a command
is EXPECTED to be part of a linked command sequence. The best 
solution I can think of is to report to the upper layer driver that
a linked command CDB has been received, and do a disconnect before
sending Status and the appropriate message. The driver can allocate
resources for follow-on CDB, then the SIM/XPT can send Status, 
Linked Command Complete (maybe With Flag), and go to Command Phase
for the next (linked) command.

Another option is just to reject all linked commands with CHECK
CONDITION Status as an illegal request.

{024} I think the proper terminology for the discretion of the 
implementor is "implementation dependent", so the sentence should
read :
For notification message handling, the SIM/HBA shall maintain, in an
implementation dependent manner, certain state information about the
message.

{028} "one-to-one", please. This is a compound modifier of the term
"correspondence".

{029} This is an awkward construct. I think it should read :
A Host Target Mode LUN shall have no more than one sequence 
identifier in use at any time.

{030} Change this to read:
A sequence identifier is "in use" from the time peripheral driver
callback is invoked until the receipt of Notify Acknowledgement from 
the peripheral driver.

{031} Make it "The ordering of Host ..." and I'll be happier.

{032} Make it :
The change to Bus Free phase and the peripheral driver callback in
clause 11.3.3.1 may occur in either order, but both steps are
required.

{038} I think it should read:
All CONTINUE TARGET I/O CCBs for this I_T_L nexus shall have the CAM
status set to Request Aborted by Host. This status shall be returned
to the Host Target Mode peripheral driver using the CONTINUE TARGET
I/O CCB callback mechanism.

{039} see {038} above (or maybe Ralph's comment {040}, not duplicated
here).

{046} I don't understand why the words "that the SIM/HBA owns" are
there. The SIM/HBA has no knowledge of any other CCBs. I think we
can dispense with this phrase.

{047} I think it is even clearer if worded:
Message handling is described ...

{056} This includes a requirement, without the magic "shall" word.
I think it should read:
The Send Status Bit is for CONTINUE I/O CCBs only. The ENABLE LUN
CCB shall specify either Host Target Mode or Phase Cognizant Mode.

{071} I think we should also refer to SCSI-2 here, so add at the
end:
"as specified in SCSI-2."

{071}(the second one) I think the business of forming sense data must
come before maintaining it, so this should read:
"... responsible for forming sense data, if applicable, and for 
maintaining it."

{072} I expect that an Editor's Note is an internal thing which will
be removed before the document is forwarded. As long as the Editor
understands his Note, we can probably stop worrying about its
wording. On the other hand, if this is a Note that implementors will
need, its name should be changed to reflect reality.

{078} Maybe it's just me, but I would find these notes less confusing
if they were a bulleted list, rather than prose. Also, the part about
"no action taken" would read better as follows:
"... the timeout period ends but no action is taken."

{079} This may not be the right answer either, but the simple way 
out of this dilemma is to suspend timeout counting until the 
CONTINUE TARGET I/O CCB is received. Obviously, this raises the
question of what to do if the driver loses it.  I would like to 
hear some other people's thoughts on this issue.

{090} I think the term "suffered" has some connotational baggage.
Perhaps "experienced" would be acceptable?

{099} In my opinion, the use of code 011B for the Peripheral
Qualifier is overly strict for a device capable of supporting all
LUNs simply by receiving the appropriate ENABLE LUN CCB. I would
suggest we use code 001B (Indicating that the device is not
currently attached at that LUN, but could be at some other time.
Furthermore, if the LUN can be activated, it must be as some 
device type, most likely the Processor Device type. So that value
goes into the Peripheral device type field. This makes the value
of byte 0 returned as 23H. However, if the SIM/HBA is capable of
supporting more than the one device type, then a value of 1FH for
an unknown device is acceptable.

I think the ordering of the values is also important to making
this easy to understand. I would propose the following wording:

If the SIM receives a CDB for the INQUIRY command for a non-enabled LUN,
the SIM shall return only byte 0 of the inquiry data. The peripheral
qualifier field shall be set to 001B indicating that the target is
capable of supporting a device on this LUN, but that no device is
currently attached at this LUN. The Peripheral device type field shall
be set to 1FH indicating an unknown device type, or to the device type
that the SIM/HBA is capable of supporting. Thus, if unknown device type
is reported, the value of inquiry data byte 0 will be 3FH.

{100} In Ralph's proposed text, there is a disagreement of subject and
verb. It should read:
If a command other than INQUIRY or REQUEST SENSE is received ...


Gary Porter                                    Voice      (415)322-5322
Ancot Corporation                              FAX        (415)322-0455
115 Constitution Drive                         E-mail   garyp at ancot.com
Menlo Park, CA 94025                           Flames          >dev/nul




More information about the T10 mailing list