linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKON4OwwOnP9kbN0JqR5L+F1svTucAQvz0RDwqU+Gy9UAFwHog@mail.gmail.com>
Date:	Thu, 25 Jul 2013 20:27:15 -0400
From:	"jonsmirl@...il.com" <jonsmirl@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Jason Cooper <jason@...edaemon.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <robherring2@...il.com>,
	Olof Johansson <olof@...om.net>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"ksummit-2013-discuss@...ts.linuxfoundation.org" 
	<ksummit-2013-discuss@...ts.linuxfoundation.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Domenico Andreoli <cavokz@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dave P Martin <Dave.Martin@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]

On Thu, Jul 25, 2013 at 7:18 PM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> On Thu, Jul 25, 2013 at 03:31:35PM -0400, Jason Cooper wrote:
>> On Thu, Jul 25, 2013 at 02:11:31PM -0500, Rob Herring wrote:
>> > On Thu, Jul 25, 2013 at 11:09 AM, Olof Johansson <olof@...om.net> wrote:
>>
>> > > 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.
>> >
>> > I think a time based stabilization period would be better than a
>> > separate directory to apply bindings too. Or time plus periodic review
>> > perhaps.
>>
>> The only problem with a time-based versus separate directory is how do
>> users who've downloaded the tree determine which bindings are stable?
>> If they pull a tarball, or receive an SDK, there is most likely no git
>> history attached.
>>
>> I think the idea of a 'tentative' directory (or 'locked') is churnish,
>> but necessary.  If I DL'd a tarball and had to type 'tentative' to get
>> to the binding doc I wanted, that would be a pretty clear clue to be
>> delicate about how I trust/use/plan with that binding.
>
> It's actually extremely simple.  If the bindings are in development,
> they must not appear in a -final released kernel.  Anything that appears
> in a -final kernel becomes part of the ABI at that point.
>
> That obviously does not mean you remove them in the last -rc and put
> them back during the merge window!
>
> That's how we handle every other ABI thing in the kernel tree, why should
> DT files be any different?  (I've added Linus and Grant to this discussion.)
>
> As I've already stated, it is intended to eventually remove the DT files
> from the kernel tree and have them as a separately maintained project,
> which means they will be independent of the kernel version.
> --
> 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/

Having a schema system for the device trees is closely related to this
discussion.  In this case the schema would probably be equal to the
stable set of nodes. This has been discussed before on the device tree
mailing list. The dtc compiler would take this schema and validate the
trees it compiles against it issuing warnings for 'non-standard'
usage. Over time the schema would be updated to allow these usages
when everyone agrees to it. Note that there would be a single schema
describing all possible legal Linux device trees.

The scheme is also quite useful for new tree developers since it will
show them the universe of device tree attributes that have already
been standardized. By using comments, you could probably turn the
device tree documentation into the schema source files.

-- 
Jon Smirl
jonsmirl@...il.com
--
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/