To avoid making a statement based on personal opinion, here is an answer based on my experience in the RF networking field and embedded ARM device programmer as an observer of inter-company shenanigans (rather than as a standard or collaboration participant / implementer)

Factors to consider when deciding to support a given standard / collaborative effort:

• Are there more more companies than the usual suspects who are often ‘there to minimise impact on their own interests’ players. => There are very few companies involved and there doesn’t appear to be any real backing from user groups at the time of writing.

• Are there established release specifications to work to, or is it all up in the air possibly waiting for (the squabbling to die down and achieve) agreement => no releases made, not a mature ‘collaboration’.

• Do you need to join to get access to appreciable documentation => I don’t know.

• Is it significant effort for you to implement and maintain compliance => Only you can say.

• Are there any competing standards / ‘collaborations’ that would hinder uptake of this one or be a possible alternative choice => yes, for ARM devices there is embed for which ARM is a significant promoter.

Based on the above simple analysis I would suggest that device tree should not be your highest priority. NB: This doesn’t mean you shouldn’t do it though.

In general:

• an OS should use some kind of tree data structure to keep track of the relationships between pieces of hardware

• (in my opinion) this should be a complete tree (e.g. should include the coffee cup warmer that’s plugged into a USB hub that’s plugged into a USB controller that’s plugged into a thunderbolt port) so that it can be used for power management (e.g. which devices connected to a USB hub should be put to sleep before the USB hub is put to sleep?) and hot-plug events (e.g. if the USB hub is removed what else must’ve been removed?)

• a complete tree can’t be static. Almost everything is potentially hot-pluggable (PCI, SATA, USB, …) while the OS is running (not just when the computer is turned off), and therefore the tree needs to be maintained/dynamically modified while the OS is running

• a complete tree needs assistance from device drivers. When you start a driver for one thing (e.g. USB controller) then that driver is responsible for detecting child devices (e.g. if a USB hub is plugged into the USB controller, then USB controller driver adds “USB hub” to the tree).

• during boot, an OS should use auto-detection as much as possible to build its device tree; because it’s far less hassle for everyone (end users, device manufacturers, system builders, …). For modern 80×86 PC compatible machines the entire tree can be built purely using auto-detection (primarily due to a industry wide push in the 1990s that became necessary because the old “manual end-user settings in config.sys” methods were unsustainable and inadequate for hot-plug purposes, which led to the inclusion of device enumeration being built into all later standards and “plug & play” standards retro-actively adding discover-ability to older technologies like ISA).

• sadly, especially for embedded systems, there are cases where auto-detection can’t be used. For these cases an OS has to rely on “ugly hacks to work around the hardware design failures” (e.g. the lack of standardised device enumeration).

Now, none of the above has anything to do with DeviceTree – it’s all about the OS’s own internal tree. However, think about that last bullet point…

DeviceTree is a relatively good “de-facto standard” that exists (and is used by multiple operating systems) to fill that last “ugly hacks to work around the hardware design failures” niche. For its intended purpose (allowing an OS to initialise its internal tree up to the point where auto-detection and drivers can begin), there is no better alternative that I know of.

In other words; (in my opinion) DeviceTree is the way to go for some cases (e.g. most embedded systems) and is definitely not the way to go for other cases (e.g. modern 80×86 systems, ARM servers).