LWN: Comments on "An alternative device-tree source language" https://lwn.net/Articles/730217/ This is a special feed containing comments posted to the individual LWN article titled "An alternative device-tree source language". en-us Sun, 12 Oct 2025 18:58:17 +0000 Sun, 12 Oct 2025 18:58:17 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net An alternative device-tree source language https://lwn.net/Articles/731310/ https://lwn.net/Articles/731310/ andy_shev <div class="FormattedComment"> Not enough chaos in chaotic device tree world, let's add a bit more...<br> </div> Thu, 17 Aug 2017 14:07:04 +0000 Why not JSON? https://lwn.net/Articles/731240/ https://lwn.net/Articles/731240/ gowen <blockquote><i>Comments is my #</i></blockquote> Stopped reading at this point :) Thu, 17 Aug 2017 08:10:32 +0000 An alternative device-tree source language https://lwn.net/Articles/730733/ https://lwn.net/Articles/730733/ robert_s <div class="FormattedComment"> I have a deep hatred of YAML and the ugly complexity hidden inside it.<br> </div> Sat, 12 Aug 2017 13:30:07 +0000 Why not JSON? https://lwn.net/Articles/730730/ https://lwn.net/Articles/730730/ mbunkus <div class="FormattedComment"> Exactly. A lot of folks assume that JSON's number type is limited the same way JavaScript's is, but that simply isn't true. The JSON spec does not limit it at all. JSON is independent of JavaScript.<br> <p> As an example of how wide-spread this false assumption is, look at Qt[1]. Their JSON implementation stores all numbers internally as doubles, losing significant precision for large integer values. This bug has been present for the whole Qt5 lifetime and is still unsolved, making the implementation completely unusable for interfacing with external systems where you do not have control over the data format.<br> <p> [1] <a href="https://bugreports.qt.io/browse/QTBUG-28560">https://bugreports.qt.io/browse/QTBUG-28560</a><br> </div> Sat, 12 Aug 2017 09:51:14 +0000 Why not JSON? https://lwn.net/Articles/730671/ https://lwn.net/Articles/730671/ nybble41 <div class="FormattedComment"> <font class="QuotedText">&gt; JSON doesn't have 64-bit integers.</font><br> <p> The JSON "number" type has no limitations on the range. All 64-bit integers, both signed and unsigned, can be encoded as JSON numbers. It is true that not all JSON parsers *read* such integers accurately; for example, JavaScript treats all numbers as double-precision floating point, and thus can only handle 53-bit integers without rounding. However, this is a limitation of the parser, not the file format. One needs to be careful when selecting tools to manipulate JSON files to ensure that the full precision of the original data is preserved.<br> </div> Fri, 11 Aug 2017 18:26:49 +0000 Why not JSON? https://lwn.net/Articles/730638/ https://lwn.net/Articles/730638/ BenHutchings <div class="FormattedComment"> JSON doesn't have 64-bit integers.<br> </div> Fri, 11 Aug 2017 16:00:33 +0000 Why not XML? https://lwn.net/Articles/730633/ https://lwn.net/Articles/730633/ nix <div class="FormattedComment"> I suspect because the kernel developers do not want to be driven completely mad -- and struggling with the unreadability of XML, the even worse unreadability of XSD and the near unavailability of XSD validators that run at sane speeds and actually do what they're supposed to (let alone those that aren't written in Java and don't pull in half the universe)... well, this doesn't seem like a thing very likely to fly very far with people as generally interested in functional minimalism as kernel developers.<br> </div> Fri, 11 Aug 2017 15:34:41 +0000 yaml in the bootloader? https://lwn.net/Articles/730524/ https://lwn.net/Articles/730524/ ukleinek <div class="FormattedComment"> <font class="QuotedText">&gt; You will never have to edit a YAML file the way that DTB now requires</font><br> <font class="QuotedText">&gt; bootloader to modify the blob to pass things like the command line to</font><br> <font class="QuotedText">&gt; the kernel, mac addresses etc.</font><br> <p> What happens behind the scene isn't that important. Today I can (in barebox) do:<br> <p> # of_property -s eth0 status disabled<br> <p> to set the status property that the alias eth0 points to to disabled. Setting bootargs is similar:<br> <p> # global linux.bootargs.tralala="rootwait"<br> <p> to append "rootwait" to the kernel parameter list. This works independent of the boot method (dt or atags).<br> <p> IMHO this is simple enough and I fail to imagine how this will get better with yaml.<br> <p> Sorry, I don't see the downside of the bootloader working with a dtb compared to yaml + yaml-to-dtb compiler.<br> <p> Do you argue that the UI gets easier or the backing code? I would doubt both for now. (Also, if you target the backing code, you have to offer real benefits, just changing working code to use a different format because you can isn't very compelling.)<br> <p> Best regards<br> Uwe<br> <p> <p> </div> Thu, 10 Aug 2017 21:01:23 +0000 yaml in the bootloader? https://lwn.net/Articles/730522/ https://lwn.net/Articles/730522/ pantoniou <div class="FormattedComment"> Err, no.<br> <p> In YAML documents are clearly marked by the --- marker.<br> <p> You will never have to edit a YAML file the way that DTB now requires bootloader to modify the blob to pass things like the command line to the kernel, mac addresses etc.<br> <p> In YAML you merely paste the new edits.<br> <p> So... if you have a boot YAML source that has a chosen node:<br> <p> chosen: &amp;chosen<br> foo: blargh<br> <p> To add a the bootargs to the kernel you append the following the original boot blob.<br> <p> ---<br> *chosen:<br> bootargs: "linux kernel bootargs"<br> <p> So, it's actually so much simpler than editing the DTB.<br> <p> </div> Thu, 10 Aug 2017 19:58:23 +0000 yaml in the bootloader? https://lwn.net/Articles/730518/ https://lwn.net/Articles/730518/ ukleinek <div class="FormattedComment"> <font class="QuotedText">&gt; Simplified YAML can even be easily understood by low-level code like bootloaders;</font><br> <font class="QuotedText">&gt; that, in turn, makes it possible (and relatively easy) for the bootloader to edit the</font><br> <font class="QuotedText">&gt; device tree on the fly at system boot time. </font><br> <p> That would mean however that the bootloader doesn't only feature a yaml parser, but also a yaml-to-dtb compiler as the kernel expects a compiled device tree, not a source file.<br> <p> Also note that U-Boot and barebox are both able to modify the compiled device tree before jumping into Linux. That is for example used to pass kernel parameters, the mac address for an ethernet device, the partitioning of a NAND chip or the available amount of RAM.<br> <p> </div> Thu, 10 Aug 2017 19:06:11 +0000 Why not XML? https://lwn.net/Articles/730475/ https://lwn.net/Articles/730475/ meyert <div class="FormattedComment"> There is also a standard for validation of structures called XSD...<br> </div> Thu, 10 Aug 2017 13:43:51 +0000 An alternative device-tree source language https://lwn.net/Articles/730448/ https://lwn.net/Articles/730448/ pantoniou <div class="FormattedComment"> There is one, it's a patch for DTC that outputs YAML instead of DTB.<br> <p> Now this converts the generated output file, it does not do anything about the sources.<br> <p> Since DTS input is preprocessed and DTC throws away type information while parsing it is hard to do an accurate translation.<br> Source files are not particularly complicated though, so someone might write a tool that works on a source level and gets most of it right.<br> <p> Manual inspection will be needed.<br> </div> Thu, 10 Aug 2017 11:17:29 +0000 Why not JSON? https://lwn.net/Articles/730447/ https://lwn.net/Articles/730447/ mathstuf <div class="FormattedComment"> If all you want are comments and you're not coding to a strict spec (i.e., extra keys are allowed), you can add "__comment" fields to JSON, but they're clunky and only fit in around dictionary fields (good luck commenting a large array of integers).<br> </div> Thu, 10 Aug 2017 11:09:30 +0000 Why not JSON? https://lwn.net/Articles/730445/ https://lwn.net/Articles/730445/ dbnichol <div class="FormattedComment"> Comments is my #1 reason to prefer YAML over JSON. Every time I find myself writing any non-trivial JSON document I get frustrated that I can't put comments in explaining what's going on. I then have to write another document next to the JSON explaining what's going on in the JSON and hope other people will read it (and that I'll remember to update it the next time I touch the JSON file).<br> </div> Thu, 10 Aug 2017 10:58:53 +0000 Why not JSON? https://lwn.net/Articles/730437/ https://lwn.net/Articles/730437/ jond <div class="FormattedComment"> If human-legibility is a driver, then YAML is a much better choice than JSON, which was "designed" (really, re-purposed) as a data interchange format first and foremost.<br> </div> Thu, 10 Aug 2017 09:28:14 +0000 An alternative device-tree source language https://lwn.net/Articles/730436/ https://lwn.net/Articles/730436/ grawity If there was a "dts2yaml" tool, wouldn't that improve the situation a bit without requiring to officially add a new format? Validators could just as easily read from a pipe. Thu, 10 Aug 2017 09:23:38 +0000 An alternative device-tree source language https://lwn.net/Articles/730431/ https://lwn.net/Articles/730431/ pantoniou <div class="FormattedComment"> Interesting. Didn't know you picked stuff from lists other than the kernel mailing list.<br> <p> FYI, things are much further along that what the article describes.<br> <p> The most important is that an eBPF based validator based on the YAML schemas posted a couple of years back by robh is almost ready.<br> <p> I will follow up with a number of blog entries at our company website in the following weeks explaining things in detail...<br> <p> Please feel free to ask questions in this thread.<br> </div> Thu, 10 Aug 2017 07:02:53 +0000 Why not JSON? https://lwn.net/Articles/730427/ https://lwn.net/Articles/730427/ drag <div class="FormattedComment"> Any good yaml document should be easily convertible to json and visa versa. If you end up with a yaml document that isn't easily converted to json it's a pretty mean thing to do to somebody.<br> <p> YAML is nice for smallish configuration files you want easily readable by humans. But for parsing and dealing with lots of data Json wins hands down. Even for human readability it gets very easy to get lost when yaml document sizes grow beyond a certain size.<br> <p> But either is fine really as long as they are easily convertible to one another. They are actually quite complimentary in practice. Lots of times when I deal with large amounts of json format I will use 'jq' or some similar tool to shrink what I am dealing with down to the specific hunk I am interested in and then convert to yaml if I need to do hand editing or whatever. <br> </div> Thu, 10 Aug 2017 05:15:47 +0000 Why not JSON? https://lwn.net/Articles/730424/ https://lwn.net/Articles/730424/ josh <div class="FormattedComment"> I was questioning the phrase "in a sense it is going with JSON".<br> </div> Thu, 10 Aug 2017 04:05:31 +0000 Why not JSON? https://lwn.net/Articles/730422/ https://lwn.net/Articles/730422/ Paf <div class="FormattedComment"> I think you've misunderstood the meaning of "superset" here.<br> <p> Specifically, it means "All JSON is YAML, not all YAML is JSON". JSON is valid YAML, YAML is not necessarily JSON.<br> <p> So YAML is JSON, and other things too.<br> <p> Though I agree the other things aren't necessarily things you want. Less expressiveness can sometimes be a boon.<br> </div> Thu, 10 Aug 2017 02:46:04 +0000 Why not JSON? https://lwn.net/Articles/730412/ https://lwn.net/Articles/730412/ mathstuf <div class="FormattedComment"> Comments, * and &amp; references, and merge key (a supplemental specification) support are worth a lot however.<br> </div> Wed, 09 Aug 2017 23:31:18 +0000 An alternative device-tree source language https://lwn.net/Articles/730409/ https://lwn.net/Articles/730409/ daney <div class="FormattedComment"> <font class="QuotedText">&gt; I thought ARM64 servers had already moved away from device tree toward ACPI.</font><br> <p> They have, but we still have to consider the set of devices running the Linux kernel that are not data-center servers.<br> <p> Considering the example from the article, most ACPI based servers probably don't have green LEDs, but for embedded devices that do, device tree is the state-of-the-art way to describe how they are connected.<br> </div> Wed, 09 Aug 2017 23:28:01 +0000 Why not JSON? https://lwn.net/Articles/730407/ https://lwn.net/Articles/730407/ josh <div class="FormattedComment"> Not quite; it's a superset of the *expressiveness* of JSON, but YAML doesn't parse as JSON.<br> <p> I do want to see this use a regularized data format. I do think that YAML has a bit too much magic for this purpose, though, such as its handling of strings, and some of the indentation and list corner cases.<br> </div> Wed, 09 Aug 2017 23:14:18 +0000 Why not JSON? https://lwn.net/Articles/730400/ https://lwn.net/Articles/730400/ corbet YAML is a superset of JSON as I understand it, so in a sense it <i>is</i> going with JSON... Wed, 09 Aug 2017 21:56:03 +0000 Why not JSON? https://lwn.net/Articles/730398/ https://lwn.net/Articles/730398/ shemminger <div class="FormattedComment"> The existing DT format looks a lot like JSON already, why not go that direction?<br> There are lots of tools for editing and parsing JSON already.<br> </div> Wed, 09 Aug 2017 21:50:05 +0000 An alternative device-tree source language https://lwn.net/Articles/730397/ https://lwn.net/Articles/730397/ creese <div class="FormattedComment"> I thought ARM64 servers had already moved away from device tree toward ACPI. <br> </div> Wed, 09 Aug 2017 21:49:06 +0000