Contents

Overview

This wiki page is a work in progress, reflecting some of the current thinking of
me (Frank Rowand, frowand (dot) list (at) gmail (dot) com). It is not a complete
compendium of the state and direction of devicetree overlays. I will update
this page as my opinions change and as discussion occurs.
Other people may have different opinions.

Please do not edit this page to reflect your opinions. If you think
that there is a factual error on this page, please email me asking that
I correct it.

If you have a differing opinion, you can either

email it to me and I will add it to this page, noting that the item is your opinion by attaching your initials to it, or

use the Discussion tab to start a conversation (to be honest, I have never used the Discussion feature in this wiki, so I do not know how well that will work)

I will attempt to incorporate information from the Discussion tab into this page, again with initials attached to indicate the source of differing opinions

I am likely to disagree with myself. I don't know how I will notate that when
I edit this page to reflect when I change my opinion. Maybe strikeouts, maybe
place dates on various conflicting opinions -- I'll figure that out as needed.

Current Status

In my opinion, the devicetree overlay implementation in the Linux kernel is
a proof of concept. I do not consider it to be even alpha complete.

issues and what needs to be completed -- Not an exhaustive list

kernel support of property and/or node changes at run-time

The current process is to be very restrictive about what overlays can touch, and carefully become less restrictive. We can't have it be wide open and then lock things down later and break users.

overlay manager

do not create this function while underlying problems still exist

might to able to phase in pieces of an overlay manager as portions of the underlying issues are resolved

refcounting issues

consider whether refcounting can be moved to the changeset or overlay level

memory leaks

node reference count bugs

adding or modifying properties to a node existing in the base devicetree

some possible corner case bugs

may lead to devicetree access API that does not expose any devicetree internal pointers

use after free bugs

node reference count bugs

may lead to devicetree access API that does not expose any devicetree internal pointers

locking is broken for the use case of overlays

how to detect whether an overlay is compatible with the base devicetree