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 09:45:51 -0400
From:	Jason Cooper <jason@...edaemon.net>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
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 02:38:02PM +0100, Russell King - ARM Linux wrote:
> 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.

We agree, I was just highlighting that attributes outside of chosen can
and need to be rewritten by the bootloader.

> 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.

Yes, the manner in which the bootloader writes the changes should adhere
to the binding.  In my example, it shouldn't replace the reg property
with reg-mod.  It should just change the addresses to reflect the
current state of the hardware the kernel will see.

thx,

Jason.
--
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/