The Device Trees concept is used in the Linux kernel to describe hardware that would otherwise not be discovered. The information about this hardware then ends up in a tree structure. This is important, for example, for ARM boards. At the Kernel Summit in Prague , the American consulting group Konsulko put forward their suggestion to change the format for these device trees to Yaml. That was a radical change, but it could well be worthwhile because of some advantages.
Status quo is complicated
The handling of device trees usually follows a fixed scheme on Linux systems. From the so-called Device Tree Source Files, a compiler dynamically generates an in-memory tree. This tree in memory is then serialized ( flattened ) to create a Device Tree Blob (DTB). This file ends up on the corresponding device itself. At the same time, the bootloader learns where it finds it, for example on a file system or in non-volatile memory.
The boot loader fetches the DTB and either passes it on to the operating system unchanged or makes small changes to it. He modifies about the boot command line. The operating system re-deserializes the binary object using an interface created for this purpose. It creates another in-memory tree, possibly with the boot loader changes.
The started kernel uses this tree structure, which is also called a “live tree” . The operating system scans the structure, initializes, and configures the associated device. To do this, it needs to know all the nodes and properties of the active node, because the access methods need that information. But this is a point where potentially errors come into play, because about the Type information is lost.
Where it hooks
The scenario just described applies mainly to individual machines. If, for example, a single image is used for different but very similar platforms, then for each supported platform, separate Device Tree Blobs (DTBs) must be produced. Even if the changes are minimal. FPGAs or expansion boards need changes to the device tree at runtime, using device tree overlays. They work subtly different than the in-memory trees.
In order for Device Trees to work smoothly, several components (compiler, bootloader, operating system) must end up working together without errors. That this does not always work, is partly due to the previously used format, which still carries some inconsistencies in itself. For example, if properties are defined as individual values or a sequence of values, their type information is lost. However, errors in dealing with device trees are not noticed until late, namely when the computer tries to boot the system. Then it usually just hangs on, without giving an indication of the cause.
Yaml should help
According to Konsulko, the Yaml format is intended to remedy this situation. It not only covers all DTS features, but is easier to read by humans, easy to parse and subsequently to change. Yaml is also widely used, mature and therefore has good support in various tools. It supports references, anchors and types for properties and accompanies the complete compilation process with useful error messages. Also Yaml can be used as Object Files as an intermediate format to postpone the final link to a later date. Last but not least, Yaml is future-proof, because the data can easily be converted into future formats.
The idea generator seems to be gradually replacing traditional DTS files with Yaml files. Whether all kernel developers agree with the proposal must be proven. In the workshop, however, there seemed to be no fundamental reservations. Json and XML as formats rejected the developers in the workshop. XML is too bulky. Json does not support Yaml, while Yaml supports Json. However, open questions also raise diffing and versioning.
0 Comments