SBP-2: Status block *src* field

Stephen_Finch at notes.ssi1.com Stephen_Finch at notes.ssi1.com
Tue Apr 7 08:57:04 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Stephen_Finch at notes.ssi1.com
*

I am in full agreement with Peter as to the problem.  His solution works.
Another solution is to
change the definition of the src field and make it applicable only to
non-management agents and
reserved for management agents.

steve





PJohansson <PJohansson at aol.com> on 04/04/98 06:58:31 PM

To:   T10 at Symbios.COM
cc:
Subject:  SBP-2: Status block *src* field




* 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




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