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

From: Domenico Andreoli
Date: Thu Jul 25 2013 - 17:41:43 EST

On Thu, Jul 25, 2013 at 11:53:49AM -0700, Stephen Warren wrote:
> On 07/25/2013 11:48 AM, Richard Cochran wrote:
> > On Thu, Jul 25, 2013 at 07:29:20PM +0100, Mark Rutland wrote:
> >> On Thu, Jul 25, 2013 at 07:05:48PM +0100, Stephen Warren wrote:
> >>>
> >>> I don't think having people "rely" on the bindings is the issue so much
> >>> as the awareness that if they do, there will be compatibility issues for
> >>> unstable bindings.
> >>
> >> As long as we can make sufficiently clear that trying to use an unstable
> >> binding is going to be *very* painful, and not necessarily supported.
> >
> > Oh, man.
> >
> > The introduction of DT into ARM Linux was supposed to make everyone's
> > life sooo much easier. Of course, based on experience with powerpc, I
> > never believed it*, but still I would expect to hear that the DT
> > bindings are, well, a *binding* contract between the board developer,
> > boot loader, and the kernel.
> >
> > Once it is working with a particular kernel, a DT board description
> > file should continue to work indefinitely with newer kernels. Anything
> > less is a regression, pure and simple.
> >
> > If you go around changing the bindings willy nilly, then what is point
> > of having DT at all?
> That's exactly why we're starting to think about which bindings should
> be considered stable and immutable, and when that should happen. As Olof
> pointed out, we haven't fully enforced that yet. Preferably bindings
> will be marked stable very fast, but mistakes are always going to happen
> in early development. ABIs are very hard.

If it was possible to clearly distinguish stable and unstable bindings,
then the kernel could allow unstable bindings only from appended DTBs.

This would prevent unwanted DT ABIs while leaving plenty of room for
the developers.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at