Re: [PATCH v10 3/4] dtc: Plugin and fixup support

Hi Phil,

On Nov 29, 2016, at 12:50 , Phil Elwell [off-list ref] wrote:

On 29/11/2016 10:39, Pantelis Antoniou wrote:

quoted

Hi Phil,

quoted

On Nov 29, 2016, at 12:32 , Phil Elwell [off-list ref] wrote:

On 29/11/2016 02:11, David Gibson wrote:

quoted

On Mon, Nov 28, 2016 at 12:24:20PM +0000, Phil Elwell wrote:

quoted

On 28/11/2016 12:10, Pantelis Antoniou wrote:

quoted

For plugins we need the __symbols__ node to support stacked overlays, i.e.
overlays referring label that were introduced by a previous overlay.

Although it is arguably useful to be able to refer to symbols created by
one overlay from within another, do we really want all symbols to be
global? Isn't there a call for a new syntax or usage pattern to indicate
either that a symbol should be local to the overlay or, my preferred
option, global?

So, this is back to a design question about the overlay format.  As
noted in the initial discussions about possible "connector" formats, I
think we will want some sort of local symbols.  But the current
overlay format with all global symbols is out there and we need to
support it.

The overlay format we have does not dictate the scope of the symbols.

In all implementations I know of - the Raspberry Pi loader, the current
Linux kernel, the latest dtc patch set - there is a completely
asymmetric relationship between the base DTB and an overlay:
* the base DTB exports __symbols__ to resolve the overlays unresolved
label references, as recorded by the __fixups__ node
* the overlay's phandles are renumbered so as not to clash with the base
tree using the __local_fixups__
* the contents of the __overlay__ nodes are applied to the base tree, as
directed by the "target" or "target-path” properties

Yes

quoted

The __symbols__ node of the overlay is ignored and discarded. The
__fixups__ and __local_fixups__ in the base DTB (if present - the RPi
dtc only generates them for /plugins/) are ignored.

That was a limitation that no-longer applies. Overlay symbols can be added
to the base tree symbol list with a small patch I have already posted.

The fact that they can doesn't mean they necessarily should.

quoted

quoted

In the set of RPi overlays only one exports a global symbol, which it
achieves with an overlay aimed at target-path = "/__symbols__" that adds
a new symbol (in this case "i2c_gpio").

If the __symbols__ in an overlay are automatically merged with the base
symbols, that is a significant change in semantics which needs to be
discussed.

You no longer need to do this anymore. Hope this helps :)

Not really, no. With the current scheme we have control over the scope,
but now there is none.

Manually adding symbols by targeting __symbols__ is just bad. There is absolutely
no guarantee that the symbol/fixup node(s) will still be there in following iterations
of the patches.

I am thinking of parsing them, recording the information in kernel structures and then
deleting them altogether.

How does your patch handle duplicate symbols?

It doesn’t. Having duplicate global symbols is bad. 

It appears you want scoping rules instead. Care to paste a concrete example?

Phil

Regards

— Pantelis