User: Password:
|
|
Subscribe / Log in / New account

Device trees I: Are we having fun yet?

Device trees I: Are we having fun yet?

Posted Nov 14, 2013 21:24 UTC (Thu) by scottwood (subscriber, #74349)
In reply to: Device trees I: Are we having fun yet? by mjg59
Parent article: Device trees I: Are we having fun yet?

Not having a fixed device tree ABI breaks use cases such as a boot loader fixing up portions based on run time information, or a hypervisor using it to tell the guest OS what devices the VM has been configured with, or sharing the tree with other OSes (we do all of these on Freescale PPC, and on some ARM boards the device tree is shared with U-Boot -- not just to pass to the kernel, but for U-Boot to learn about the hardware). A fixed ABI is how it works with actual Open Firmware, and is how ACPI works, etc. Likewise with PCI -- it works because there's a standard, that isn't subject to revision as part of Linux patch acceptance.

Granted, it's harder to standardize things well when the hardware being described is changing so rapidly, but by treating the device tree as a Linux implementation detail rather than an ABI, you take away the incentive to get it (reasonably close to) right the first time. You could still have a separate Linux-internal tree (we already do -- struct device and friends) that encodes Linux concepts and/or fixes quirks in the hardware tree, which is generated from the hardware tree plus quirk code in the kernel, and possibly some supplementary external data file which *is* a Linux implementation detail and not meant for sharing with other components. In extreme cases the "quirk and supplementary external data" could be an entire replacement tree, if the standard one is hopeless for anything other than identifying which replacement tree to use, but most cases should not be that bad.

Moving the hardware tree outside the kernel source would send a clear message that it is not a Linux implementation detail (and thus compatibility between the trees and OSes including but not limited to Linux needs to be considered), and that things which are need to go somewhere else.

Also note that the dts sometimes contains implementation details of the bootloader -- it may make assumptions about how the loader sets up the address map, or it may make assumptions about what things the loader will fill in before passing the tree to the kernel. Both of these are true on Freescale PPC. In those cases ideally the trees would be stored in the bootloader tree.


(Log in to post comments)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds