On Wed, Sep 09, 2020 at 09:07:29AM +0200, Greg KH wrote: > On Tue, Sep 08, 2020 at 11:14:11AM -0700, James Bottomley wrote: > > On Tue, 2020-09-08 at 21:05 +0300, Jarkko Sakkinen wrote: > > > On Tue, Sep 08, 2020 at 07:45:52AM +0200, Greg KH wrote: > > > > On Mon, Sep 07, 2020 at 02:52:08PM -0700, James Bottomley wrote: > > [...] > > > > > I've got to say I think binary attributes are actively evil. I > > > > > can see > > > > > they're a necessity when there's no good way to represent the > > > > > data they > > > > > contain, like the bios measurement log or firmware code or a raw > > > > > interface like we do for the SMP frame code in libsas. But when > > > > > there's a well understood and easy to produce user friendly non- > > > > > binary > > > > > representation, I think dumping binary is inimical to being a > > > > > good API. > > > > > > > > Agreed. > > > > > > > > thanks, > > > > > > > > greg k-h > > > > > > Looking at the patch, something like <device>/pcrs/<hash>/<index> > > > would be a bit cleaner representation than the current <device>/pcrs- > > > <hash>/<index>. > > > > That's actually a technical limitation of using the current attribute > > groups API: It's designed to support single level directories in sysfs > > (or no directory at all). That's not to say we can't do multi-level > > ones, but if we do we have to roll our own machinery for managing the > > files rather than relying on the groups API. > > Agreed, do NOT do multi-level attribute groups please, userspace tools > will not handle them well, if at all. OK, thanks for confirming this. /Jarkko
