On Tue, Feb 21, 2017 at 9:46 PM, Nadathur, Sundar <sundar.nadat...@intel.com> wrote: > On February 21, 2017 9:39 PM, Moritz Fischer wrote: > >> TLV Seems easy enough. To give an update, I played with fdt a bit to see how >> far I get in half an hour. I got bool / int / strings to work quite fast >> (~30mins). >> Please disregard the horrible hackyness of this ... >> [...] >> So I'm fairly convinced I can make this work, TVLs seem like it could work, >> too. >> >> > So far the only thing we know we need is a 'bool' for encrypted and a >> > stringish guid thing for partial reconfiguration. > > These things have a way of growing beyond their original anticipated needs.
True. But yeah, not sure about the requirement for a tree, maybe it is overkill. > Say we upstream a metadata parser. Subsequently, an FPGA image is released > with an additional metadata field that the upstreamed version does not > handle. How will this be handled if the metadata were in FDT or KVP format? The code above will gently ignore it, as I said I spent about half an hour on writing that, just to prove to myself it can be done easily. Logically I don't see anything wrong with ignoring features from the future. But if one insisted one could make a compatibility number part of the required properties I suppose and error out instead. There are examples of optional properties in the devicetree parsing code in the kernel. That being said older drivers / fpga-mgr will not deal with newer features. TLV / KV or whatever doesn't change this fact, or am I missing something? Adding new properties to devicetrees is a well known exercise to cope with newer versions or variations of hardware and happens all the time in the kernel. Older kernels will just ignore them. Thanks, Moritz