All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Hannes Reinecke <hare@suse.de>
Cc: James Bottomley <jbottomley@parallels.com>, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 1/2] Use sdev_scsi2lun for SCSI parallel drivers
Date: Mon, 7 Jul 2014 02:37:46 -0700	[thread overview]
Message-ID: <20140707093746.GA12985@infradead.org> (raw)
In-Reply-To: <53BA524B.7060400@suse.de>

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.


  parent reply	other threads:[~2014-07-07  9:37 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 [this message]
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
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=20140707093746.GA12985@infradead.org \
    --to=hch@infradead.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.