Re: [PATCH v7 4/5] dtc: Plugin and fixup support

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3452 bytes --]

On Thu, Jun 02, 2016 at 08:13:51PM +0300, Pantelis Antoniou wrote:
> Hi David,
> 
> > On May 31, 2016, at 08:06 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> > 
> > On Fri, May 27, 2016 at 05:33:06PM +1000, David Gibson wrote:
> >> On Tue, May 24, 2016 at 08:50:38PM +0300, Pantelis Antoniou wrote:
> >>> 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 <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >>> Signed-off-by: Jan Luebbe <jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >> 
> >> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]