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@xxxxxxxxxxxx>
> > Signed-off-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>
> > Signed-off-by: Jan Luebbe <jlu@xxxxxxxxxxxxxx>
>
> 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
--
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:
signature.asc
Description: PGP signature
