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:	Sat, 27 Jul 2013 12:36:30 +0200
From:	Tomasz Figa <tomasz.figa@...il.com>
To:	Arend van Spriel <arend@...adcom.com>
Cc:	Richard Cochran <richardcochran@...il.com>,
	Olof Johansson <olof@...om.net>,
	Mark Brown <broonie@...nel.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>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	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 Saturday 27 of July 2013 12:24:24 Arend van Spriel wrote:
> On 07/27/2013 11:51 AM, Tomasz Figa wrote:
> > On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:
> >> On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:
> >>> Long term, final goal is likely to be close to what Russell is
> >>> saying
> >> 
> >> Why is this a long term goal? Start today.
> >> 
> >>> -- nothing should go into the kernel tree unless the binding is in a
> >>> fully stable state. However, we have a transitional period between
> >>> now
> >>> and then, and even when we're at the final state there will be need
> >>> to
> >>> have some sort of sandbox for development and test of future
> >>> bindings.
> >> 
> >> Why not just set up a git tree right away?
> >> 
> >>> Dealing with all that, as well as the actual process for locking in
> >>> bindings, is what needs to be sorted out.
> >>> 
> >>> I think we're all in agreement that bindings that change over time
> >>> are
> >>> nothing but pain, but we're arguing that in circles anyway.
> >> 
> >> No.
> >> 
> >> I keep saying, the bindings must be stable ABI, *today*.
> >> 
> >> You keep saying, maybe later, but until then we will make things up
> >> as
> >> we go along.
> > 
> > We have currently a lot of broken bindings, because people didn't know
> > how to define ones and those they defined have not been properly
> > reviewed. Do you really want such broken ABI in the kernel?
> > 
> > Sure, there are many existing bindings that can be just made stable
> > and
> > well they probably are already de facto stable. This is mostly about
> > subsystem bindings and whatever already has many users, both made them
> > get more thought when designing and more review before merging.
> > 
> > Still, a lot of device and platform-specific bindings are simply
> > broken. Take max8925 backlight driver, that Olof started this whole
> > discussion with, as an example. We need to sort them out before they
> > can be stabilized.
> 
> That is a nice summary of how we got from null to now and Richard seems
> to be simply saying: let's stop mucking about and make this a project
> with a well-defined process of dealing with staging and stable bindings
> and keep stable bindings stable. Whether it should be within the kernel
> repo as a separate subsystem or in an entire different repo is a trivial
> decision, but still a decision that needs to be made.

Yes, basically that's our current situation.

Still, I would disagree about the decision being trivial, as each choice 
will have further, and likely pretty significant, consequences on binding 
maintenance, submission, review and for dependent things, like drivers or 
platforms using such bindings. This needs to be discussed enough.

> Apart from stable DT bindings I would love to see a DT compiler that
> that next to DT syntax detects mistakes in properties used for the
> selfish reason that I spent hours debugging regulator code, because I
> typed vmmc_supply iso vmmc-supply. I did not go through all the
> bindings, but this may require a more formal description so it could be
> compiled/read in the DT compiler.

This bothered me as well and that's why I'm working on this. I still can't 
get myself to write a very long mail (I'm more a coder than writer...) 
about the whole idea, my proposal of how it could look and problems we 
need to solve, but I'll try better this evening.

Best regards,
Tomasz

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