linux-kernel - Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

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:	Mon, 26 May 2014 17:09:44 +0200
From:	Sebastian Reichel <sre@...g0.de>
To:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Rob Herring <robherring2@...il.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Matt Porter <matt.porter@...aro.org>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Alison Chaiken <Alison_Chaiken@...tor.com>,
	Dinh Nguyen <dinh.linux@...il.com>,
	Jan Lubbe <jluebbe@...net.de>,
	Alexander Sverdlin <alexander.sverdlin@....com>,
	Michael Stickel <ms@...able.de>,
	Guenter Roeck <linux@...ck-us.net>,
	Dirk Behme <dirk.behme@...il.com>,
	Alan Tull <delicious.quinoa@...il.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Michael Bohan <mbohan@...eaurora.org>,
	Ionut Nicu <ioan.nicu.ext@....com>,
	Michal Simek <monstr@...str.eu>,
	Matt Ranostay <mranostay@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Pete Popov <pete.popov@...sulko.com>,
	Dan Malek <dan.malek@...sulko.com>,
	Georgi Vlaev <georgi.vlaev@...sulko.com>
Subject: Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

Hi,

On Mon, May 26, 2014 at 02:55:37PM +0300, Pantelis Antoniou wrote:
> On May 26, 2014, at 2:23 PM, Grant Likely wrote:
> > On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > Heeheehee. We're back where we started. The original question is whether
> > or not that is a valid approach. If the overlay represents something
> > that can be hot plugged/unplugged, then passing it through to the second
> > kernel would be the wrong thing to do. If it was a permenant addition,
> > then it probably doesn't need to be removed.
> > 
> > We do actually keep the overlay info in memory for the purpose of
> > removal exactly so we can support hot unbinding of devices and drivers
> > that make use of overlays.
> 
> We can support either method. I am not feeling any wiser about which one should be
> the default TBH, so what about exporting a property and let the platform 
> figure out which is more appropriate?

What about supporting "negative" overlays (so an overlay, that
removes DT entries)? That way one could reverse apply an overlay.
All the dependency stuff would basically be the users problem.  The
kernel only checks if it can apply an overlay (and return some error
code if it can't). This this code is needed anyway to check the
input from userspace.

As a result the overlay handling would basically have the same
behaviour as diff and patch :)

P.S.: Sorry if this has already been suggested. I have only read
mails from PATCHv4.

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)