On Thu, Jun 02, 2016 at 08:13:51PM +0300, Pantelis Antoniou wrote:

Hi David,

quoted

On May 31, 2016, at 08:06 , David Gibson [off-list ref] wrote:

On Fri, May 27, 2016 at 05:33:06PM +1000, David Gibson wrote:

quoted

On Tue, May 24, 2016 at 08:50:38PM +0300, Pantelis Antoniou wrote:

quoted

This patch enable the generation of symbols & local fixup information
for trees compiled with the -@ (--symbols) option.

Using this patch labels in the tree and their users emit information
in __symbols__ and __local_fixups__ nodes.

The __fixups__ node make possible the dynamic resolution of phandle
references which are present in the plugin tree but lie in the
tree that are applying the overlay against.

Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
Signed-off-by: Sascha Hauer <redacted>
Signed-off-by: Jan Luebbe <redacted>

So, I think I've identified the underlying thing which was bothering
me about these patches.

With the new dynamic patching stuff, "overlays" (for want of a better
term) now have a real existence both in the dts source format, and in
the dtb object format.  However, these patches don't give them a
concrete, explicit representation within dtc itself - instead we just
kind of mangle one representation to the other as we're parsing.  I
think this is a mistaken approach.

I'm toying with some patches to give overlays a full representation in
dtc which I think will handle these cases better - and allow for
easier experimentation with different possible ways of encoding the
overlays.

One side point - writing plugins in dts format leads to an irritating
little ambiguity in the grammar.  Well, not an ambiguity technically,
but a place where we need more lookahead than normal, meaning we get
shift/reduce conflicts.  It arises because both memreserves and
overlays can have a label in front of them.  So, if we see a label as
our next token after the version tag, we don't know if a memreserve or
overlay is coming next, so the parser doesn't know which path to go
down (with a single token lookahead).  We could handle it with
%glr-parser, of course, but I have been trying to avoid that.  I think
this will apply both with your patches and with the approach I'm
working on - not sure what to do about it yet.

I now have a first cut at said experiments, see:
   https://github.com/dgibson/dtc/tree/overlay

Rebased my work and will submit again a couple of minutes.

Everything works besides a small niggle with the overlay syntax.

You cannot get rid of the basetree token. So…

&foo { }; 

Does not work for an overlay, you need a dummy basetree 

/ { }; &foo { };

Right, it was my intention to remove that restriction but it hits the
grammar complication discussed above.  I might have to bite the bullet
and turn on %glr-parser.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson