Behavior of TEST UNIT READY command in idle and standby power conditions

Pat LaVarre p.lavarre at ieee.org
Thu Nov 29 10:48:31 PST 2012


* From the T10 Reflector (t10 at t10.org), posted by:
* Pat LaVarre <p.lavarre at ieee.org>
*
I think this thread launched by asking, is the polling for Kcq x20402
Initializing Command Required something we could simplify in some
fresh creative way?
Could we eliminate it, require it, code it always as Request Sense,
code it always as Test Unit Ready, include it in every Target's
Stopped state?
Or is it as simple as it can be already? More responsive targets don't
want it, less responsive targets need it, we somehow can't afford to
simplify our way thru that please-everyone contradiction?
> You have lots of choices (some of which work better in some circumstances
than others).
>
> I guess, what I’m saying, is that the answer isn’t a simple black or white
> (always GOOD, or always CHECK CONDITION).  Sometimes,
> you have to evaluate your internal situation and
> make a decision as to which response is appropriate for that situation.
(-: And again Fred says better than any of us what so many of us know
but few can say well.
Those sometime's happen often. That's how Scsi Interoperability is
nothing like Simple, instead Scsi works well only when enough us come
to agree in the code we ship as Initiators and Targets over what
Polite Scsi is.
The Scsi Aftermarket in particular measurably concretely commercially
rewards the Target for guessing well how the Initiator will
misunderstand. Like notice how we hear more of Interoperability
puzzles from Target people here in T10.Org email, not so much from
Initiator people. Targets that guess well just work better in the
Aftermarket, they beat out the others, even an earlier generation from
the same vendor, because they give less hassle to the Aftermarket
customers who add Targets to Initiators.
I'm less confident about how guessing well plays in the compatibility
labs of Enterprise Scsi. I've mostly seen more reasonably complete
specifications and qualifications up there, less room for guessing,
less occasion for the Initiator to be foolishly thinking of one kind
of Target while actually working with another, margin enough to pay
for thoughtful design in advance.
> I’m suggesting that
> you forget about your internal state for just a minute and
> focus on the visible behavior instead ...
> remember, these are models ...SCSI has always been
> more about the visible behavior than actual verifiable internal state.
Yes exactly.
> Yes, I know, engineering sacrilege.
Eh? Sacrilege? To whom? When? Why?
Isn't the win for this seeing of SCSI as an Interoperability Model
well established
in Postel's social engineering paradox nutshell
= """Be conservative in what you do, be liberal in what you accept
|from others."""
= ~~~ We all should code workarounds for people acting foolishly,
after failing to persuade them to change
= ~~~ An opaque bridge not liberal in what it accepts, a transparent
bridge not conservative in what it sends, Q E D no bridge delivers as
much interoperability as it appears to promise.
?
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list