Hi Heikki, On Tue, Nov 10, 2020 at 01:54:53PM +0200, Heikki Krogerus wrote: > On Fri, Oct 23, 2020 at 02:43:28PM -0700, Prashant Malani wrote: > > I've now come to the conclusion that this is not the correct approach. > Instead, the whole identity, all six VDOs, should be supplied > separately with a "raw" sysfs attribute file after all. > > The three attribute files that we already have - so id_header, > cert_stat and product - can always supply the actual VDO as is, > regardless of the product type, so they are fine. But these new > attribute files, product_type_vdoX, would behave differently as they > supply different information depending on the product type. That just > does not feel right to me. OOI: I'd like to understand the reservations around this approach. Can't userspace just read these and then interpret them appropriately according to the id_header as well as PD revision (and version number) if that's exposed? The only thing I see changing is how we name those product_type_vdoX sysfs files, i.e product_type_vdo0 == passive_cable_vdo OR active_cable_vdo1 depending on the product type. That said, perhaps I'm missing some aspect of this. > > So lets just add the "raw" sysfs attribute file. We can think about > extracting some other details from the product type VDOs once the > specification has settled down a bit and we can be quite certain that > those details will always be available. > > Would this be OK to you? I think we should be able to dump the data to > the "raw" sysfs attribute file with something like hex_dump_to_buffer(). FWIW, "raw" option SGTM (the product type VDOs can be parsed from the buffer since the format is fixed). > > thanks, > > -- > heikki
