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]

Date:	Fri, 26 Jul 2013 14:38:02 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Jason Cooper <jason@...edaemon.net>
Cc:	Richard Cochran <richardcochran@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	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>,
	Domenico Andreoli <cavokz@...il.com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	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 Fri, Jul 26, 2013 at 09:27:09AM -0400, Jason Cooper wrote:
> On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
> > 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.
> 
> The other dynamic change that bears mentioning here is attributes which
> have been configured by the bootloader.  For example, in mvebu, we have
> the Schrodinger's Cat register.  It allows you to reconfigure the base
> address of the registers from *within* that register range.  If the
> bootloader does this, the DT needs to be updated to reflect the current
> hardware configuration.  Otherwise, the kernel is stuck poking around at
> memory addresses hoping to find something sane.
> 
> But this falls into the same category as you mentioned, but outside of
> chosen {};.

No, this falls within the remit of "describing the hardware" and it is
certainly something that is free to change.

What should not "change" once a kernel is the method by which hardware is
described in DT.  "change" there in the sense that how it was described by
kernel 3.X should still be accepted by 3.X+n, even if 3.X+n comes up with
a much better way to describe it.

The actual data associated with those descriptions is free to change in
whatever way is necessary if the hardware itself changes due to things
being programmed differently.

Think of it as the difference between the design of an interface, and the
interface being used.  We don't mandate that the write() syscall shall
always be called for fd=1 with length=5 and bytes "Hello" in the buffer.
We mandate that the write() syscall shall be passed an integer fd, a
buffer pointer, and a length and we don't change that ever.

Think of "a better way to describe it" as introducing the writev() syscall
to supplement write() so that applications can do writes from scattered
memory locations.  We don't get rid of the write() syscall - we add to
the ABI that's already there leaving the existing interfaces with exactly
the same semantics, so that all the existing stuff continues to work as-is.
--
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/