Thread (142 messages) 142 messages, 28 authors, 2013-08-14

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

From: Matt Porter <hidden>
Date: 2013-07-29 15:46:05
Also in: lkml

On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:
On Fri, Jul 26, 2013 at 7:10 AM, Mark Brown [off-list ref] wrote:
quoted
On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
quoted
Unless I totally misunderstood, the thread is talking about letting
established bindings change with each new kernel version.  I am
opposed to that.
No, nobody is really saying that is a particularly good idea.  There is
some debate about how we work out what an established binding is but
there's no serious suggestion that we don't want stable bindings.
Yes, what Mark said -- _today_ all bindings are subject to change and
can be changed in lockstep with the kernel. This has been necessary as
part of development to sort out all of the various bootstrapping
issues across platforms.
However, we still have people arguing that we can't (or should not) change
a binding right now even to fix inconsistency issues that are discovered
after the fact. I'm hearing a different story depending on who is
telling it at the moment.

Getting quickly to a definitive answer on the criteria for an
"established" binding is will help end ongoing discussions as to whether
we can fix a currently broken one or just have to leave it.
What we're talking about is to end that mode of operation, and moving
over to locking in bindings. Device tree contents, as mentioned
elsewhere, might still be changed just like code is -- bugs are fixed,
etc. But it's time to start locking down the bindings, in particular
no longer change the established ones.

Long term, final goal is likely to be close to what Russell is saying
-- nothing should go into the kernel tree unless the binding is in a
fully stable state. However, we have a transitional period between now
and then, and even when we're at the final state there will be need to
have some sort of sandbox for development and test of future bindings.
Dealing with all that, as well as the actual process for locking in
bindings, is what needs to be sorted out.

I think we're all in agreement that bindings that change over time are
nothing but pain, but we're arguing that in circles anyway.
+1

-Matt
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help