SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe

plavarre at lexar.com plavarre at lexar.com
Thu Jan 3 09:00:22 PST 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
> Now what I think Pat is trying
Hi. Thought-provoking to see this small issue so persistently confused
in such a broad variety of ways offline and online.
I have now a reading kindly contributed offline that I think is the
intent of what we published, just not actually in technical agreement
with the words we have mistyped into Spcr411.pdf:
"""In order to get the information that tells you how many bytes of data
are available the allocation length must be at least this big. If you
don't care about retrieving the Page Length parameter or the Available
Length parameter then you don't have to follow this suggestion."""
Is this indeed what we were trying to say?
I think we have to agree over what we were trying to say before we have
a hope of saying it accurately.
I think that's what we actually meant to say.
> > > If the EVPD bit is ...
Looks like some reviewers get lost in the truth of the real dichotomy
that the host must choose zero or one as the EVPD bit of the CDB. That
dichotomy is very true, it is only one bit, it can only be zero or one,
yes yes yes. But the rest of the above is true also.
> highlight that setting ALLOCATION LENGTH to zero in an INQUIRY command
is allowed,
Several readers offline also appear to get lost in "shall" vs. "should".
I think here we published a false combination of should's, not a false
combination of shall's.
I think the text as it stands contains two nearly adjacent should's that
misleadingly combine to produce the false claim that the host "should
not" zero allocation length. I agree the two should's don't combine to
produce the false claim that the host "shall not".
> I think this is covered.
I'm failing to follow that logic of that assertion, somehow. I've seen
several people make it, online or offline. Always looks to me like
people mixing should's with shall's, as if shall's could cover should's.
> Why the value in the ALLOCATION LENGTH should be set to five or four
> is already explained by the cross references in 6.4.1 INQUIRY command
introduction,
> albeit not as clearly as my suggested wording, but definitely more
succinctly.
Yes.
> Wow. Three "ly" adverbs in one sentence -- ha!
:-)
> The qualification for the five or four in the ALLOCATION LENGTH field
> in an INQUIRY command as defined in 6.4.1 is only a "should".
Yes.
> Based on that text, zero is allowed as a value in the field for
whatever reason.
Sure, by Spc4r11 the host may choose allocation lengths between 0 and
65,535.
Another confusion offline appeared between transfer length and
allocation length. The field in Inquiry is allocation length, where the
code zero means a count of zero bytes, never a transfer length such as
the code zero in op 08h Read(6) that can mean a count of
two-hundred-fifty-six blocks.
> In addition, the second paragraph in 4.3.4.6 Allocation length reads,
> "An allocation length of zero specifies that no data shall be
transferred.
>  This condition shall not be considered as an error."
> So, 6.4.1 implicitly permits zero as an allowed value for an INQUIRY
command,
> and 4.3.4.6 explicity allows a value of zero in an ALLOCATION LENGTH
field for any command.
Yes. Our "shall"s are not broken, only our "should"s are at issue.
> I think that there are many words that could be added
> to further explain the setting of the ALLOCATION LENGTH field
> in an INQUIRY command.  However, "the standard [already] says so."
This slang is new to me.
I think this means we should not add words to the standard when the
standard already says what it means?
I'm ok with that principle.
Here's I'm confident that the standard doesn't yet say what we mean. It
includes a false host should not.
> Pat, if you want some more words in SPC-4,
> I'd suggest submitting a proposal to T10,
Ok.
> based on what is already in the standard, I think you may have tough
sledding.
Ok.
I'm curious to know if I'm wrong. Left to myself I'd be certain I'm
obviously right, but meeting together like this we've at least proved
that I'm not obviously right, even if I am right, and we still hold open
the idea I might be wrong, which might interest me a lot more than
anyone else.
> ...
I popped up online yesterday and offline immediately received the
following suggestion. I posted it once but I haven't seen anyone quote
it, kind of like it got lost because it arrived online under my same
>From tag so soon?
Kindly offline we have an alternative preferred there:
"""The ALLOCATION LENGTH field is defined in 4.3.4.6. If EVPD is set to
zero, the allocation length should be [+ zero else] at least five, so
that the ADDITIONAL LENGTH field in the parameter data (see 6.4.2) is
returned. If EVPD is set to one, the allocation length should be [-
should be] [+ zero else] at least four, so that the PAGE LENGTH field in
the parameter data (see 7.6) is returned."""
I think that proposed change text actually says what we mean, i.e.:
"""In order to get the information that tells you how many bytes of data
are available the allocation length must be at least this big. If you
don't care about retrieving the Page Length parameter or the Available
Length parameter then you don't have to follow this suggestion."""
I can volunteer me to format some Word doc if that would help, sure.
None of these words are originally mine, thanks again to everyone
involved,
*
* 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