SBP-2: Status block *src* field

PJohansson PJohansson at aol.com
Sat Apr 4 18:58:31 PST 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* PJohansson <PJohansson at aol.com>
*
Please consider this as a very late ballot comment. We have some minor things
to discuss Wednesday morning, May 6, in Colorado Springs. I'd like this to be
one of them.

I think the definition of the src field in the status block (see 5.3) should
be changed. For one thing, it's wrong as it stands. For another, I think this
change makes better sense.

This affects src values of zero and one, only. The src values for unsolicited
status are unchanged. Here is the present definition:

0 The status block pertains to an ORB identified by ORB_offset_hi and
ORB_offset_lo; at the time the ORB was most recently fetched by the target the
next_ORB field did not contain a null pointer.

1 The status block pertains to an ORB identified by ORB_offset_hi and
ORB_offset_lo; either the next_ORB field is absent or at the time the ORB was
most recently fetched by the target the next_ORB field was null.

As described above, status blocks for ORBs sent to the MANAGEMENT_AGENT would
always return src equal to one. Turn to 9.3 for a description of how the
initiator is supposed to use src. One case in particular is interesting: "When
src has a value of one, the system memory shall not be reused or deallocated
until the target stores completion status for some subsequent ORB in the
linked list." Pretty tough for the initiator to *ever* reuse management ORBs,
since they're not part of any linked list!

I suggest that the use of src should be: zero, it's OK to release the ORB
because the target won't fetch it again, and one, it's not OK to release the
ORB until some later event occurs. In formal terms:

0 The status block pertains to an ORB identified by ORB_offset_hi and
ORB_offset_lo; either the ORB does not contain a next_ORB field or else at the
time the ORB was most recently fetched by the target the next_ORB field did
not contain a null pointer.

1 The status block pertains to an ORB identified by ORB_offset_hi and
ORB_offset_lo; at the time the ORB was most recently fetched by the target the
next_ORB field was null.

It is late in the process to make a change but I think it's likely that no
initiator implementation will be affected. If an initiator first examines the
status block for src == 0 it will correctly release ORBs (both management and
linked-list flavors) when it is safe to do so. If the initiator code first
examines the ORB type to which the status block pertains, I suspect that if it
is for a management ORB that src is ignored. In other words, a target that
returned src == 0 for management ORBs interoperates correctly with initiator
software, regardless.

Target firmware that at present returns src == 1 for management ORBs would
need to be revised to be compliant.

Comments?

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson at aol.com


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list