All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Hannes Reinecke <hare@suse.de>
Cc: Bart Van Assche <bvanassche@acm.org>,
	James Bottomley <jbottomley@parallels.com>,
	Christoph Hellwig <hch@infradead.org>,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH 2/2] ib_srp: 64bit LUN fixes
Date: Fri, 4 Jul 2014 06:48:35 -0700	[thread overview]
Message-ID: <20140704134835.GB12345@infradead.org> (raw)
In-Reply-To: <53B6A5B4.2040807@suse.de>

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?


  reply	other threads:[~2014-07-04 13:48 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 [this message]
2014-07-04 14:12         ` Hannes Reinecke
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=20140704134835.GB12345@infradead.org \
    --to=hch@infradead.org \
    --cc=bvanassche@acm.org \
    --cc=hare@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.