On Tue, 2014-03-11 at 12:56 +0100, Hannes Reinecke wrote: > On 03/11/2014 05:14 AM, James Bottomley wrote: > > On Mon, 2014-03-10 at 21:52 +0100, Hannes Reinecke wrote: > >> On 03/10/2014 07:24 PM, James Bottomley wrote: > >>> On Mon, 2014-03-10 at 15:28 +0100, Hannes Reinecke wrote: > >>>> EVPD page 0x83 is used to uniquely identify the device. > >>>> So instead of having each and every program issue a separate > >>>> SG_IO call to retrieve this information it does make far more > >>>> sense to display it in sysfs. > >>> > >>> Christoph's suggestion of binary sysfs attributes for this rather than > >>> the text ones you have is better ... because your current ones are going > >>> to truncate when they run off the one page of data sysfs text attributes > >>> get (i.e. about 2k of vpd). > >>> > >> Yes, I thought of that, too. > >> I thought to remember that binary attributes are reserved for > >> firmware/hardware-dependent interfaces. > >> If that's not the case I'll be moving to a binary attribute here. > >> Will be resending the patchset. > >> > >> What should happen with the first patch in the series, then? > >> When moving to a binary attribute the first patch isn't required > >> anymore; should I drop it or send as a separate patch? > > > > It can be applied separately. > > > > I also still think we can get around the caching problem by requesting > > the vpd page every time. Arrays will change it under us and the cache > > will go stale. Even enclosures sometimes swallow unplug plug events and > > simply change the vpd data. > > > Hmm. The whole idea of having the vpd data in sysfs is precisely so that > one does _not_ have to do I/O to access it. No, the point is to provide a uniform interface to User Space to prevent *userspace* from having to do I/O (which it frequently gets wrong). What we do under the covers is up to us. What's the reason for not wanting to do I/O every time? Getting VPD data isn't a time critical operation is it? so what's the benefit of caching it? James > I think using a flag to invalidate data would be better here. > > And will keep Bart happy :-) > > Will be updating the patchset. > > Cheers, > > Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
