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: Russell King - ARM Linux <hidden>
Date: 2013-07-26 13:18:46
Also in: lkml

On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
On Fri, Jul 26, 2013 at 10:42:24AM +0100, David Woodhouse wrote:
quoted
On Fri, 2013-07-26 at 10:01 +0200, Richard Cochran wrote:
quoted
On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
quoted
We use DT has a kernel configuration input. Our environment is
designed to guarantee 100% that the kernel and DT match exactly. DT
very deliberately isn't an ABI boundary in our systems.
Think about what you just said.

The DT describes the *hardware* not the kernel. Why should you ever
need to update your DT at all?
Well, the nodes which describe hardware devices, according to the
bindings which form an ABI contract between DT and drivers, should not
normally change. Although they *can* change, if for example you change
the MAC address and that's stored there. Or you change the PHY you want
it to use. Or something like that. The *ABI* doesn't change, but the
data you express *using* that ABI can change. That's kind of the point.
Unless I totally misunderstood, the thread is talking about letting
established bindings change with each new kernel version.  I am
opposed to that.

Of course, a user may want to change the values of his MAC addresses,
if he needs to. But he should never have to change *how* he specifies
those addresses.

So, as long as everyone can agree to the principle that a working DT
should remain working after a kernel upgrade, then I'll shut up. In
actual fact, this is not the case today, nor was it ever so in the
past, AFAICT, but it never hurts to set goals.
We agree.

That's precisely why I'm saying that once a binding appears in a -final
released kernel, it is _stable_ by that very fact.  If there were any
doubts about it, it should never have been accepted into the kernel tree
in the first place.

It's no different from how we treat syscalls.  Once we accept a syscall
and it's published in a -final kernel, it can't then be altered - it can
be supplemented by a new syscall with a different interface, but the old
one remains and keeps its semantics for a great many years.

There's no reason for DT to be any different in this regard.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help