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:	Wed, 31 Jul 2013 12:37:37 +0200
From:	Maxime Bizon <mbizon@...ebox.fr>
To:	Tomasz Figa <tomasz.figa@...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>,
	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>,
	Olof Johansson <olof@...om.net>,
	Mark Brown <broonie@...nel.org>,
	Arend van Spriel <arend@...adcom.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 Sat, 2013-07-27 at 11:51 -0700, Tomasz Figa wrote:

> Well, it depends on how we use the DT. There are (at least) two possible 
> usage scenarios:
> 
>  a) using DT as direct replacement for board files - this means that you 
>     are free to say that DTSes are strictly coupled with kernel version 
>     and you are free to modify the bindings - see the analogy to board 
>     files, where you could modify the platform data structures and could 
>     not directly copy board file from one kernel version to another,

I'm shocked to see this as a possible option.

Board files are C code anyone has the skill to edit/understand/refactor.
Moving to DT and keep them in tree tightly coupled with the kernel
version just adds another layer of indirection for *no purpose*.

The fact that we loose compiler syntax/type checking (as highlighted
somewhere else in this thread) even looks like a regression.


>  b) using DT as an ABI - this is the original way, i.e. define stable 
>     bindings and make sure that anu DTB built for older kernel will
> work, with equal or greater set of functionality on newer kernels.
> 
Linus started the whole thing some years ago by refusing to pull ARM
tree [1]. Reread his post, what he wants is clearly b).

Going a) does not solve any problem. You are just moving churn to
somewhere else. We had board files churn, then defconfigs churn, DTS
files (and associated drivers) will be next.

DT is self inflicted pain. It has to be for the greater good.

Going b) *might* allow what some people here dream about, a kernel free
of hardware knowledge. A new board could boot a kernel compiled before
it was even designed.

Now since I do "embedded" stuff everyday, I don't think b) can apply to
the whole ARM world. There is just to much hardware peculiarity.


[1] https://lkml.org/lkml/2011/3/30/525

-- 
Maxime


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ