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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
Date:	Thu, 25 Jul 2013 09:09:19 -0700
From:	Olof Johansson <olof@...om.net>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Domenico Andreoli <cavokz@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Dave P Martin <Dave.Martin@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	"ksummit-2013-discuss@...ts.linuxfoundation.org" 
	<ksummit-2013-discuss@...ts.linuxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: DT bindings as ABI [was: Do we have people interested in device tree
 janitoring / cleanup?]

[I'm adding LKML and ksummit-discuss to this thread, since the ACPI/DT
discussions have been covered there and this overlaps some with that]

On Thu, Jul 25, 2013 at 7:38 AM, Catalin Marinas
<catalin.marinas@....com> wrote:
> On Thu, Jul 25, 2013 at 03:27:02PM +0100, Russell King - ARM Linux wrote:
>> Remember the stated assertion when DT was first added to the kernel: the
>> DT descriptions _will_ become a separately maintained project which is
>> independent of the kernel.  They will _not_ be kernel version specific.
>
> I'm looking forward to this.
>
> Question for the DT guys: what are the plans here? Are we going to get
> rid of the .dts files inside the kernel tree?

In the discussions we had in Dublin, a couple of options on how to
lock in bindings were discussed. I'm a little surprised that Grant
didn't cover them in his initial emails on the new maintainership
model, but maybe he wanted the new group to handle it. And they didn't
bring it up yet either. So I am. :-)

Until now, we have been working under the assumption that the bindings
are _NOT LOCKED_. I.e. they can change as needed, and we _ARE_
assuming that the device tree has to match the kernel. That has been a
good choice as people get up to speed on what is a good binding and
not, and has given us much-needed room to adjust things as needed.
That obviously has to change, but doing so needs to be done carefully.

It's likely that we still want to have a period in which a binding is
tentative and can be changed. Sometimes we don't know what we really
want until after we've used it a while, and sometimes we, like
everybody else, make mistakes on what is a good idea and not. The
alternative is to grind most new binding proposals to a halt while we
spend mind-numbing hours and hours on polishing every single aspect of
the binding to a perfect shine, since we can't go back and fix it.

So, there really seems to be a need for a layered approach, one in
which a binding "graduates" from being tentative to being locked in.
I'm refraining from using the terms "staging" and "stable" here, since
they have overloaded meaning in the kernel world that doesn't apply
here.

One problem that needs to be solved is obviously how a binding
graduates from tentative to locked. This work isn't going to be very
interesting to most people, I suspect. Think standards committee type
work.

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.

I think that captures most of what we discussed in person. Others
might have changed their opinions since then, so I'm definitely not
claiming that any of this was an official decision made by anybody.
It's just one proposal on how to handle these things moving forward.

-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/