Re: [PATCH 1/2] fdt: Allow stacked overlays phandle references

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

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

On Thu, Jul 13, 2017 at 12:31:50PM -0700, Frank Rowand wrote:
> On 07/03/17 02:06, David Gibson wrote:
> > On Wed, Jun 14, 2017 at 05:52:25PM +0300, Pantelis Antoniou wrote:
> >> This patch enables an overlay to refer to a previous overlay's
> >> labels by performing a merge of symbol information at application
> >> time.
> > 
> > This seems to be doing things the hard way.
> > 
> > You're essentially extending the semantics of overlay application to
> > add the symbol merging.  You've implemented these extended semantics
> > in libfdt, which is all very well, but that's not the only overlay
> > application implementation.
> > 
> > 
> > It seems to me a better approach would be to change dtc's -@
> > implementation, so that in /plugin/ mode instead of making a global
> > __symbols__ node, it puts it into the individual fragments.  That way
> > the existing overlay application semantics will update the __symbols__
> > node.
> 
> If the __symbols__ node was inside a fragment, then the existing
> code would add (or update) a __symbols__ node located at the location
> pointed to by the fragment's target path, instead of updating the
> node /__symbols__.

No, what I meant was that an overlay can update anything, including
__symbols__, so you could have a fragment which made the __symbols__
updates.

But I realised shortly afterwards that doesn't work, because we don't
know the correct resolved target paths.

> It makes sense to me to have only one global __symbols__ node instead
> of several.

Having realized the above, that does make sense.

> If there is a global __symbols__ node then we have a single name
> space for symbols.
> 
> If there are multiple __symbols__ nodes spread throughout the tree,
> then to me that would imply different name spaces spread throughout
> the tree, where namespaces are determined by fragments.  This sounds
> confusing to me.  Or if the intent is to have a single name space
> then the __symbols__ information would be scattered throughout the
> tree instead of located in a single node.
> 
> My current patch (under review), targeted for Linux 4.13-rc1, puts
> an overlay's __symbols__ node properties into the overlay's
> changeset, so they get added when the overlay is loaded and
> removed when the overlay is unloaded.

True, but not relevant to what I was proposing.

-- 
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: 833 bytes --]