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

On Thu, Jul 13, 2017 at 12:31:50PM -0700, Frank Rowand wrote:

On 07/03/17 02:06, David Gibson wrote:

quoted

On Wed, Jun 14, 2017 at 05:52:25PM +0300, Pantelis Antoniou wrote:

quoted

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