From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Hannes Reinecke <hare@suse.de>,
linux-scsi@vger.kernel.org, Jeremy Linton <jlinton@tributary.com>,
Kay Sievers <kay@vrfy.org>, Doug Gilbert <dgilbert@interlog.com>,
Kai Makisara <kai.makisara@kolumbus.fi>
Subject: Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs
Date: Fri, 07 Mar 2014 14:57:47 +0400 [thread overview]
Message-ID: <1394189867.14365.4.camel@dabdike> (raw)
In-Reply-To: <20140307104321.GA28472@infradead.org>
On Fri, 2014-03-07 at 02:43 -0800, Christoph Hellwig wrote:
> On Fri, Mar 07, 2014 at 02:40:00PM +0400, James Bottomley wrote:
> > On Thu, 2014-03-06 at 10:01 +0100, Hannes Reinecke wrote:
> > > So the only 'proper' solution would be to add a bitmap of supported
> > > pages; however, this would be 256 bits = 32 bytes of additional
> > > space required for struct sdev.
> > > Which I'm a bit reluctant do to, as it'll be a sparse array in most
> > > cases, adding to quite some wasted space.
> >
> > Why per sdev? Isn't it per target? The supported EVPD page list
> > shouldn't really vary for luns of the same target unless something very
> > strange is happening in the array.
>
> It might very well vary. For one difference device types support
> different EVPD patches and a target might mix and match device types for
> LUNs.
Yes, cardreaders can do this, I suppose, but they're not a usual case
> Also software targets might use individual LUNs as passthrough
> to physical devices, in which case they might support different EVPD
> pages even for the same device type. E.g. the pscsi backend for the
> in-kernel target might behave like that.
This is a bit of a stretch too. However, I can't see an easy way of
supporting the common case (same EVPD array per lun) simply and allowing
for the more complex one, so I suppose if we do it it will have to be
per sdev.
James
next prev parent reply other threads:[~2014-03-07 10:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-13 10:07 [PATCHv7 0/3] Display EVPD pages in sysfs Hannes Reinecke
2014-02-13 10:07 ` [PATCH 1/3] scsi_sysfs: Implement 'is_visible' callback Hannes Reinecke
2014-02-13 10:07 ` [PATCH 2/3] Add EVPD page 0x83 to sysfs Hannes Reinecke
2014-02-28 17:01 ` Christoph Hellwig
2014-03-05 7:38 ` Hannes Reinecke
2014-03-05 19:42 ` Christoph Hellwig
2014-03-06 9:01 ` Hannes Reinecke
2014-03-07 10:11 ` Christoph Hellwig
2014-03-07 10:35 ` Hannes Reinecke
2014-03-07 10:44 ` Christoph Hellwig
2014-03-07 10:39 ` James Bottomley
2014-03-07 10:51 ` Hannes Reinecke
2014-03-07 11:01 ` James Bottomley
2014-03-07 11:18 ` Douglas Gilbert
2014-03-07 13:39 ` Hannes Reinecke
2014-03-07 10:40 ` James Bottomley
2014-03-07 10:43 ` Christoph Hellwig
2014-03-07 10:57 ` James Bottomley [this message]
2014-02-13 10:07 ` [PATCH 3/3] Add EVPD page 0x80 " Hannes Reinecke
-- strict thread matches above, loose matches on Subject: below --
2014-02-13 10:27 [PATCHv7 0/3][Resend] Display EVPD pages in sysfs Hannes Reinecke
2014-02-13 10:28 ` [PATCH 2/3] Add EVPD page 0x83 to sysfs Hannes Reinecke
2014-03-02 8:34 ` Bart Van Assche
2014-03-05 7:56 ` Hannes Reinecke
2014-03-02 8:36 ` Bart Van Assche
2014-03-05 7:56 ` Hannes Reinecke
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=1394189867.14365.4.camel@dabdike \
--to=james.bottomley@hansenpartnership.com \
--cc=dgilbert@interlog.com \
--cc=hare@suse.de \
--cc=hch@infradead.org \
--cc=jlinton@tributary.com \
--cc=kai.makisara@kolumbus.fi \
--cc=kay@vrfy.org \
--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