SAM public review comment

Tom Wicklund wicklund at Intellistor.COM
Sat Mar 18 15:18:58 PST 1995


Attached is a copy of the public review comment I've sent regarding
the SCSI-3 Architecture Model.

3/18/95


TO:    X3 Secretariat
       ATTN: Lynn Barra
       1250 Eye Street NW, Suite 200
       Washington, DC  20005


FROM:  Thomas Wicklund
       1506 Harvard Street
       Longmont, CO  80503

       (303)-682-6549
       FAX (303)-682-6401
       email wicklund at intellistor.com


Public review comments of X3.270:199x, SCSI-3 Architecture Model (SAM)

I am working from document X3T10/994D revision 16, which I hope is
correct.

Page 42, Section 6, definition of "service response":  Input arguments
"Data-Out Buffer" and "Task Attribute" should be swapped in the
description at the middle of the page so that the order of the
descriptions matches the order in the definition.


Page 47, Section 6.2, definition of ACA ACTIVE:  Item c) refers to the
"ACA bit", it should instead refer to the "NACA bit".


Page 47, Section 6.3:  In the first paragraph of this section, the
second sentence should refer to the "Send SCSI Command Protocol
Service request" (add capitalization and the word "request").  This is
consistent with the rest of the paragraph's capitalization and use of
the words confirmation, indication, and response.


Page 56, Section 6.6.3: I think items c) and d) should contain
identical text in the second paragraph.  Item c) specifies that the
target should return sense data without specifying the sense data
(contrary to the other 3 items in this section).



Page 72, section 8.6.2:  This example (HEAD OF QUEUE tasks) is very
confusing:

1.  It isn't obvious why a group of simple tasks have an Ordered
Blocking Boundary between them (between task 2 and task 4).  I think
this is because when task 3 is accepted then subsequent simple tasks
are dormant until all head or queue tasks complete.  It might help the
example to show this since anybody who understands why the Ordered
Blocking Boundary is present at the start probably doesn't need the
example.

2.  The transition from 2 to 3 makes the dormant tasks enabled when
Head of Queue task 3 completes.  However Head or Queue task 7 is still
enabled.  It appears from this example that the term "earlier" is used
to mean issued earlier in time rather than earlier in the queue (I
suggest the term "earlier" be defined here so that it's clear).

The definition of Head of Queue seems counter-intuitive here.  If a
system normally uses only Simple tasks, there is no requirement that
Head of Queue tasks be executed before any previously accepted Simple
task (since all are in the enabled state).  In fact, I don't find
anything in the text to imply that a Head of Queue task must be placed
at the head of the task queue, merely that it be placed someplace in
the queue in enabled state.

The requirement that all earlier (in time) Head of Queue tasks be used
to determine when a task is dormant means that tasks must be queued
both by order of issue and by enabled or dormant.  This seems to add
a non-obvious burden on implementations.

I realize this has been argued over a lot, so won't suggest a
technical change, though renaming "Head of Queue tasks" to
"Immediately Enabled tasks" might be more honest.

I do suggest that this example be expanded greatly with explanations
of why "Head of Queue" doesn't really mean "execute first".




More information about the T10 mailing list