Re: [PATCH 1/2] Use sdev_scsi2lun for SCSI parallel drivers

[Hannes Reinecke <hare@suse.de>]

On 07/07/2014 11:37 AM, Christoph Hellwig wrote:
> On Mon, Jul 07, 2014 at 09:54:51AM +0200, Hannes Reinecke wrote:
>> 1) Isolate from any fallout due to the 64bit LUN changes. By introducing
>> accessors we are guaranteed that the drivers will only ever see LUN numbers
>> they are expecting.
>
> I really don't see the point.  The LUNs have to be passed up from the
> driver anyway, so seeing anything unexpect just doesn't make sense.
> Furthermore if we really are worried about this we should have asserts
> that the higher bytes aren't set, and also take care of the even more
> limited LUN size for SCSI-2.
>
>> 2) Using accessors allows us to eventually change the ->lun field to 'struct
>> scsi_lun', and call 'scsilun_to_int' only for display purposes. This will
>> address the objection by Bart for
>> ib_srp, but applies to other drivers as well.
>
> So, for any SAM based drivers struct scsi_lun is the wire format anyway,
> so those are easy.  For SCSI-2 and older we can just use scsilun_to_int
> and easily get the back the LUN that came over the wire.  Is it worth to
> micro optimize by not looking at the other fields?  I'd say no, but even
> if it is I'd rather see this as part of the series moving to embedding
> the scsi_lun.
>
> FYI, I've merged your first set of fixes for the printk specifiers, but
> I've not merged anything fixing the other warnings that the build but
> sent reports for for now.
>
Ok, so I'll be sending a patchset for fixing up the build warnings
(and keeping the current accesses to ->lun), and prepare a different 
patchset moving everything onto accessors so that we can use struct 
scsi_lun directly.
Agreed?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html