linux-kernel - Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap

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:	Tue, 13 Nov 2012 09:57:21 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	David Gibson <david@...son.dropbear.id.au>
CC:	Pantelis Antoniou <panto@...oniou-consulting.com>,
	Kevin Hilman <khilman@...com>, Matt Porter <mporter@...com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Felipe Balbi <balbi@...com>,
	Deepak Saxena <dsaxena@...aro.org>,
	Scott Wood <scottwood@...escale.com>,
	Russ Dill <Russ.Dill@...com>, linux-omap@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org
Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices
 to mach-omap2)

On 11/13/2012 12:25 AM, David Gibson wrote:
> On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote:
>> On 11/12/2012 05:10 AM, Pantelis Antoniou wrote:
> [snip]
>>> Oh yes. In fact if one was to use a single kernel image for beagleboard
>>> and beaglebone, for the cape to work for both, it is required for it's
>>> dtb to be compatible. 
>>
>> Well, as Grant pointed out, it's not actually strictly necessary for the
>> .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb
>> can be generated at run-time using dtc for example.
> 
> So, actually, I think a whole bunch of problems with phandle
> resolution disappear if we don't try to define an overlay .dtb format,
> or at least treat it only as a very shortlived object.  A more precise
> proposal below.  Note that this works more or less equally well with
> either the original overlay approach or the graft/graft-bundle
> proposal I made elsewhere.
> 
> 1) We annotate the base tree with some extra label information for
> nodes which overlays are likely to want to reference by phandle.  e.g.
> 
> 	beaglebone_pic: interrupt-controller@...XX {
> 		...
> 		phandle,symbolic-name = "beaglebone_pic";
> 	};
> 
> We could extend dtc to (optionally?) auto-generate those properties
> from its existing label syntax.  Not sure if that's a good idea or
> not yet.  In any case, we compile this augmented base tree to .dtb as
> normal and boot our kernel with it.

Yes, I think a name-based approach is preferable over using
opaque/arbitrary phandle IDs/ranges/...

> 2) The information for the capes/modules/whatever is
> distributed/packaged as .dts, never .dtb.  When userspace detects the
> new module (or the user explicitly tells it, if it's not probeable) it
> picks up the correct dts and runs it through dtc in a special mode.
> In this mode dtc takes the existing base tree (from /proc/device-tree,
> say) as well as the new dts.  In this mode, dtc allocates phandles for
> the new tree fragment so as not to collide with anything from the
> supplied base tree (as well as avoiding internal conflicts,
> obviously).  It also allows node references to the base tree by using
> those label annotations from (1) to match symbolic names to the
> phandle values in the base tree.
> 
> 3) The resulting partial .dtb for the module is highly specific to the
> base tree (which if the base tree was generated at runtime by firmware
> could even be specific to a particular boot).  But that's ok, because
> we just spit it into the kernel, absolute phandle values and all, then
> throw it away.  Next time we need the module info, we recompile it
> again.

Once you've booted with a base tree, and loaded a partial .dtb for one
child board, and are then loading a .dtb for another child board (or you
unloaded the original child board and are loading a replacement), then
presumably the current in-kernel device tree also depends on all the
runtime history too.

So then going back to your point (2), that means we need to have
user-space serialize the dtc execution so that we don't compile two new
partial .dtbs in parallel, and end up with each not conflicting with the
current in-kernel device tree, but still conflicting with each-other. I
imagine that's easily solvable though.
--
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/