On Mon, Feb 20, 2017 at 5:49 PM, Moritz Fischer <moritz.fisc...@ettus.com> wrote: > Hi Alan, > > On Sun, Feb 19, 2017 at 3:16 PM, Alan Tull <delicious.qui...@gmail.com> wrote: >> On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull <delicious.qui...@gmail.com> >> wrote: >>> On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer >>> <moritz.fisc...@ettus.com> wrote: >>>> On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote: >>>>> On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar >>>>> <sundar.nadat...@intel.com> wrote: >>>>> >>>>> > Hi all, >>>>> > Interesting discussion. The discussion so far has brought out many >>>>> > concerns such as OS independence. There is an existing format, >>>>> > well-known to developers, with widespread support, and which is quite >>>>> > extensible: Type-Length-Value triples. >>>>> > >>>>> > To elaborate, a TLV-based format has many advantages: >>>>> > * It is highly extensible in many ways >>>>> > -- You can express structures and arrays using TLVs. Our needs right >>>>> > now may seem limited but requirements grow over time. >>> >>> Device tree can express arrays. >>> >>>>> > -- The space of Type values can be decomposed into standard >>>>> > pre-defined values that are in upstreamed code, and possibly >>>>> > experimental or feature-specific values. >>>>> > -- Forward compatibility: We can write parsers that can skip >>>>> > unexpected type values, thus allowing old parsers to work with new >>>>> > additions. With some tweaks, old parsers can also reject unexpected >>>>> > values in some ranges while accepting them in other ranges. >>>>> > * It is OS-independent. >>>>> > * It can be easily parsed, in kernel or user space. >>>> >>>> Are there other users of the format? I have to admit I didn't look very >>>> long, but couldn't find any libs / existing code at a first glance. >>> >>> Is there a standard you are looking at? Have you seen any use of TLV's >>> in the Linux kernel you could point to? >>> >>>> >>>>> > * It can be validated, in terms of Type values, acceptable lengths, etc. >>>>> > >>>>> > It is not directly human-readable but that can be easily addressed >>>>> > with a tool that parses TLVs. >>>>> > >>>>> > Compared to some other proposals: >>>>> > * Compared to DTs, TLVs are OS-independent. >>>> >>>> That's just alternative facts here. Just because Linux uses fdt for >>>> devicetree blobs it is *not* OS dependent. There are several (see >>>> last email) non-Linux users of fdt / libfdt. >>>> >>>> Thanks, >>>> >>>> Moritz >>> >>> It is worth repeating that libdtc is GPL/BSD with the intent of >>> allowing proprietary code to use libdtc. So license shouldn't be a barrier. >>> >>> Using device tree in the header would give us a way of doing enumeration at >>> least for Linux, not sure if that kind of info can be used in Windows >>> in some way. >> >> Actually, enumeration is the only advantage I see with DT. > > Which seems to some point a separate issue to passing in image > specific info such as > encrypted or not, compressed or not or build info metadata. > > So I think in general we can still separate this out into: > - Image specific values > - Reconfiguration specific values > >> Currently I like key/value pairs because they are easily implemented >> and expandable without being rigid in any way. >> >> If we use key/value pairs, we could pass in child device info >> in one of the keys. It could be either a device tree overlay or an >> ACPI overlay. Or could just be left out. So platforms that >> aren't already using DT wouldn't have to. Platforms that >> are have a smooth road to enumeration. > > I'm not sure if you can bundle up enumeration info *with* the image > since you might e.g. > load the same image (i.e. same header) into different FPGAs and the > required update to > the kernel state, i.e. live tree or ACPI would depend entirely on > which FPGA you loaded > the image into w.r.t busses it's connected to etc. > > I do think this info cannot be image specific, but needs to be passed > in via something > external such as a dt overlay.
Yes, I think you are right about that. Thanks! Alan > > Cheers, > > Moritz
