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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
