On Fri, 2014-03-07 at 11:51 +0100, Hannes Reinecke wrote: > On 03/07/2014 11:39 AM, 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. > > > Spec says it's per LUN:
Specs say a lot of "interesting" things. The question is what's common practise in the field. > 7.8.16 Supported VPD Pages VPD page > The Supported VDP Pages VPD page contains a list of the VPD page > codes supported by the logical unit (see > table 637). > > so we shouldn't really make any assumptions about what might be > sensible or strange. The cardreader case is the one I think causes problems for this. Going completely the opposite direction, why do we need to cache this at all? ... it's fairly simple to request each time and it avoids worrying about the data changing because of a change in the array. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
