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. 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. Alan > > Alan
