linux-kernel - Re: [Ksummit-2013-discuss] 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: <20130731204817.GC24642@n2100.arm.linux.org.uk>
Date:	Wed, 31 Jul 2013 21:48:18 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	"jonsmirl@...il.com" <jonsmirl@...il.com>
Cc:	Richard Cochran <richardcochran@...il.com>,
	Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"ksummit-2013-discuss@...ts.linuxfoundation.org" 
	<ksummit-2013-discuss@...ts.linuxfoundation.org>,
	Ian Campbell <ian.campbell@...rix.com>,
	Pawel Moll <Pawel.Moll@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Tomasz Figa <tomasz.figa@...il.com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Domenico Andreoli <cavokz@...il.com>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Arend van Spriel <arend@...adcom.com>,
	Mark Brown <broonie@...nel.org>,
	Olof Johansson <olof@...om.net>, mbizon@...ebox.fr,
	Dave P Martin <Dave.Martin@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
	people interested in device tree janitoring / cleanup?]

On Wed, Jul 31, 2013 at 04:37:36PM -0400, jonsmirl@...il.com wrote:
> On Wed, Jul 31, 2013 at 4:14 PM, Russell King - ARM Linux
> <linux@....linux.org.uk> wrote:
> > However, if we go back to the idea that DT is supposed to describe the
> > hardware, _and_ that the way to describe that hardware is well defined
> > and _stable_ (as it should be) then there should be no reason what so
> > ever that your old DT blob should not continue working in later kernels.
> > If it doesn't, then the contract that DT promised when we first moved
> > over to using DT has been _broken_.
> 
> Suppose your DT predates PINCTRL and the CPU needs the pins set to
> function.  But setting the pins up is a board specific function. How
> is this going to get implemented in a generic kernel that doesn't have
> any board specific code in it?
> 
> I would propose that we only need to worry about DTs that got put into
> boot loaders and not worry about ones that were only used when
> appended to a kernel.

That is - again - our mistake.  We should have made it clear from the
start that the use of an _appended_ DT, or a DT provided with the kernel
being booted was more or less mandatory for the time being.  We actually
did exactly the opposite - we advertised the appended DT as a stop-gap
measure just to allow a DT kernel to be booted with a boot loader which
didn't support DT.

That in itself _encouraged_ boot loader support for DT on ARM (which in
itself is not a bad thing) but also leads people down the path of
potentially separating the DT from the kernel.

Had we encouraged the use of an appended DT instead, but still encouraged
boot loaders to update, and also made a clear statement that DT is
unstable (which everyone can see - for example by making our DT stuff
depend on CONFIG_EXPERIMENTAL when it existed) then everyone would have
been clear about its status.

The fact that we did not - the fact that we ignored this process means
that it is _our_ problem that people like Richard are blowing up such a
storm over this.  We need to admit that we got it wrong, and commit to
doing it the right way in future.  What that means is starting off today
with a commitment to keep as much of the stuff which works today working
_tomorrow_, and the day after, and so forth.
--
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/