SAM public review comment -- Pro

Charles Monia monia at am.shrmsg.shr.MTS.dec.com
Fri Apr 14 14:37:46 PDT 1995


Hi Tom:

Thank you for your public review comments on SAM. The following are my proposed
responses.
Your comments are prefaced with ">".

>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.
>
>

Proposed response: Comment Accepted.

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

Proposed response: Comment Accepted.


>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.
>
>

Proposed Response: Comment Accepted.

>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).
>

Comment rejected.

The two conditions are not identical. In case c),, since the unit is known to
be non-operational, it may be appropriate to return something other than NO
SENSE in response to a REQUEST SENSE command. In case d), the target can't tell
whether the unit is broken or not there.

Also, while c) seems like a special case of item d), I believe retaining the
distinction is useful for the sake of clarity.

>
>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.
>

Comment accepted. Rather than modify the existing example, I propose that a new
example be created to show how an HOQ task creates the ordered blocking
boundary which partitions the task set.

>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).
>
Comment accepted.

>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".

Comment accepted. Another example will be added. In addition the descriptions
will be revised to be more clear. The terminology for task attributes, however,
will not be changed.

Charles Monia






More information about the T10 mailing list