On Fri, 14 Jul 2000, Kenn Humborg wrote:
> > I had a talk with my firmware buddies, and the solution we
> > eventually implemented was to ignore those LUN bits for Inquiry
> > and Request
> > Sense commands only, all other commands will check condition as before. I
> > disagree about ignoring reserved fields, not checking reserved fields is
> > definitely a bad way to go from the firmware's perspective.
>
> [Disclaimer: The following is from a general protocol definition viewpoint.
> I don't know for fact if this applies to SCSI or to this
> particular field in SCSI. I could be very wrong.]
>
> No. No. No. The whole point of reserved fields is to allow
> for future expansion. Any device that sends a reserved field
> should fill it with some well-defined value (almost always
> zero). Any device that received a reserved field should
> ignore it.
The standard said sometimes "The recipient _may_ not check reserved bits,
...", so you _may_ be right. In other places, it said "The recipent _may_
check reserved bits, ... and report errors if non-zero ...", so you_may_
well be both right and wrong at the same time. :-)
Perhaps, latest specifications are consistent on this point, but I am sure
I have read the both statements above in earlier ones.
> Later, if newer devices need to use this field, the sender will
> fill it with a non-zero value. Older devices will still ignore
> it. Newer devices will check it, see the non-zero value and
> act accordingly.
>
> > As you
> > recommended, it's probably prudent to deviate from the spec in
> > order to be a
> > good bus device.
>
> Does the spec actually say "the receiver should check
> that reserved bits are zero?"
I does not. It may have ever said "may" and this has been enough for
paranoia to unfortunately apply, it seems.
G�rard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
