Re: standards revisions

[Christoph Hellwig <hch@infradead.org>]

On Sun, Oct 07, 2012 at 10:31:37AM -0700, Nicholas A. Bellinger wrote:
> Regardless of if an virtual backend reports a SPC-3 version (0x05) in
> INQUIRY response, an initiator is still allowed to fall back to using
> legacy SCSI-2 reservations instead of SPC-3 persistent reservations.  I
> can think of at least one mainstream SCSI initiator that does this.

Yes, but we have a different code path for the mixed SCSI-2/SPC-3
reservations from the pure SCSI-2 mode, based on the function pointers
set up in core_setup_reservations().  As far as I can see we could
only reach the SCSI-2 path there for a pscsi device that has the
emulate_reservations flag set, and even then we would never actually hit
the code the function pointers point to as we don't actually support
emulated reservations for pscsi.

> Also, I think your mistaken about ALUA and SCSI-2 compatibility.  ALUA
> is an SPC-3 and above specific feature.

What I mean is that int core_setup_alua again has a special code path
for < SCSI-3 levels, which has the same reachability issues as for the
reservations above.

> pSCSI has always NOP'ed the reservation + ALUA function pointers within
> core_setup_reservations() and core_setup_alua().

Unless the emulate_reservations or emulate_alua flags are set, in which
case we will set the other functions pointers.  That being said I can't
see why the function pointers are even needed, as the non-noop versions
are careful enough to do the right thing for pscsi as we'll never have
registrations set.  I'll send a series of patches to clean all this up.