From: Hannes Reinecke <hare@suse.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Bart Van Assche <bvanassche@acm.org>,
James Bottomley <jbottomley@parallels.com>,
linux-scsi@vger.kernel.org
Subject: Re: [PATCH 2/2] ib_srp: 64bit LUN fixes
Date: Fri, 04 Jul 2014 16:12:57 +0200 [thread overview]
Message-ID: <53B6B669.10704@suse.de> (raw)
In-Reply-To: <20140704134835.GB12345@infradead.org>
On 07/04/2014 03:48 PM, Christoph Hellwig wrote:
> On Fri, Jul 04, 2014 at 03:01:40PM +0200, Hannes Reinecke wrote:
>> What I would like to do is to provide accessor functions for the scsi lun;
>> I've started this already for the older SCSI parallel drivers (see my
>> earlier patch).
>> Once everything is moved over to accessors it should be trivial to move from
>> the current scsilun_to_int representation in struct scsi_device to the
>> 'real' LUN.
>>
>> Adding another field would be bit of an overkill IMO, seeing that we can
>> achieve the very same thing with a bit of code reshuffling.
>>
>> James, Christoph, what's your opinion on using accessors?
>> Would solve this issue nicely, and we can also use proper functions for HBAs
>> only capable of handling 32bit LUNs.
>> Drawback is that we would need accessors also for this capable of handling
>> full 64bit LUNs, thus potentially incur some overhead there.
>
> 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.
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
next prev parent reply other threads:[~2014-07-04 14:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-04 11:54 [PATCH 0/2] Fixed for 64bit LUNs Hannes Reinecke
2014-07-04 11:54 ` [PATCH 1/2] Use sdev_scsi2lun for SCSI parallel drivers Hannes Reinecke
2014-07-04 13:44 ` Christoph Hellwig
2014-07-04 14:12 ` Hannes Reinecke
2014-07-05 9:41 ` Christoph Hellwig
2014-07-07 7:54 ` Hannes Reinecke
2014-07-07 7:59 ` Hannes Reinecke
2014-07-07 9:37 ` Christoph Hellwig
2014-07-07 10:05 ` Hannes Reinecke
2014-07-07 10:11 ` Christoph Hellwig
2014-07-07 14:10 ` Hannes Reinecke
2014-07-04 19:44 ` Douglas Gilbert
2014-07-04 20:14 ` Elliott, Robert (Server Storage)
2014-07-07 5:47 ` Hannes Reinecke
2014-07-04 11:54 ` [PATCH 2/2] ib_srp: 64bit LUN fixes Hannes Reinecke
2014-07-04 12:31 ` Bart Van Assche
2014-07-04 13:01 ` Hannes Reinecke
2014-07-04 13:48 ` Christoph Hellwig
2014-07-04 14:12 ` Hannes Reinecke [this message]
2014-07-04 14:38 ` Bart Van Assche
2014-07-04 14:41 ` Hannes Reinecke
2014-07-04 16:53 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53B6B669.10704@suse.de \
--to=hare@suse.de \
--cc=bvanassche@acm.org \
--cc=hch@infradead.org \
--cc=jbottomley@parallels.com \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox