On 07/04/2014 04:38 PM, Bart Van Assche wrote:
On 07/04/14 16:12, Hannes Reinecke wrote:
On 07/04/2014 03:48 PM, Christoph Hellwig wrote:
I think storing the struct scsi_lun in the scsi_device is the right way
to go ahead. Any "accessors" for 8 or 32-bit LUNs should be simply
enough by just ignoring bits in the array, so there's very little
performance overhead.
If we can get rid of the old scalar LUN field that would be great,
and given that we know the printk format fallout already it doesn't look
like too much work. Do you want to look into this?
Already working on it.
That sounds great. Regarding the SRP initiator driver: if the "__be64
lun" declarations in <scsi/srp.h> are changed into "struct scsi_lun lun"
then that allows to encode / decode LUNs inside the SRP initiator
without having to cast the address of these "lun" members into struct
scsi_lun *. In case you would prefer me to have a look into this, please
let me know.
That would be perfect.
Most of the HBAs supporting 64bit LUNs internally are already doing
this.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
