DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Ian Campbell]

On Thu, 2013-07-25 at 18:57 +0100, Mark Rutland wrote:
> > A possible way to handle this is to have exactly that: A group of
> > people that essentially constitute the "standards committee" that meet
> > on a regular basis to review and approve new bindings. They should be
> > people not just doing ARM Linux work, but other stakeholders in these
> > bindings too. One of the things they should probably do is sift
> > through our current in-kernel bindings and select those who seem ready
> > to be locked in, review/discuss/decide upon that and once the decision
> > is made, that specific binding does become part of the static,
> > never-ever-change ABI of firmware-to-kernel interfaces.   That might
> > also be the time that the binding is moved from the kernel to a
> > separate repo, but that's a technicality that we'll let the DT
> > maintainers decide among themselves, IMHO.
> 
> We're going to need input from other OSs too, or the bindings will
> remain Linux-specific regardless of how far away the bindings and dts
> repo(s) is/are.

FWIW my primary interest in stable DT ABIs is because Xen would like to
consume the same device trees on boot, as well as be able to do other
clever things with DT at runtime. Specifically:
      * Take the host device tree passed to Xen at boot, filter out the
        stuff which Xen uses for itself (which is for the most part core
        architectural stuff) and pass the remainder to the dom0 Linux
        kernel (or perhaps in the future another kernel) to drive the
        remainder of the hardware (mostly the SoC specific stuff, but
        some architectural and some Xen defined stuff too)
      * Generate a suitable DT for a guest domain on the fly depending
        on the guest configuration.

Obviously both of those need a stable ABI for us to understand,
manipulate and generate.

Ian.