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

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

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

On Thu, Jul 13, 2017 at 02:40:12PM -0700, Frank Rowand wrote:
> On 07/13/17 14:22, Phil Elwell wrote:
> > On 13/07/2017 21:07, Frank Rowand wrote:
> >> On 07/13/17 12:38, Phil Elwell wrote:
> >>
> >> (I moved Phil's reply to after the email he replied to.)
> > 
> > Thanks.
> > 
> >>> On 13 Jul 2017 8:32 pm, "Frank Rowand" <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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__.
> >>>>
> >>>> It makes sense to me to have only one global __symbols__ node instead
> >>>> of several.
> >>>>
> >>>> 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.
> >>
> >>> Can we also consider a mechanism for overlay-local symbols, i.e. symbols
> >>> that are used purely to create links within an overlay - perhaps using a
> >>> particular naming convention? This would make it easier to instantiate an
> >>> overlay multiple times without having to uniquify all symbols, and it would
> >>> avoid polluting the global namespace without reason.
> >>>
> >>> Phil
> >>
> >> That is essentially the result you get if you compile the overlay dts
> >> without '-@'.  There will be no __symbols__ node created even if there
> >> are symbols within the overlay.
> > 
> > But (unless something has changed recently) the '-@' switch controls both
> > symbol and fixup generation, i.e. export and import of symbols. Unless one
> > religiously uses 'target-path' to place fragments (thus removing the
> > level of abstraction provided by symbols) overlays are useless without
> > the ability to reference external symbols, but in my experience very few
> > overlays need to add symbols to the global symbol table.
> 
> For the dtc compiler in Linux 4.11, the '-@' switch is only needed
> to generate the __symbols__ node.  The __fixups__ and __local-fixups__
> nodes are generated whether '-@' is specified or not.
> 
> The __fixups__ and __local_fixups__ are generated when '/plugin/;'
> is specified in the source file.

Yup, i.e. something *has* changed recently.

Building fixups based on -@ never made any sense.

-- 
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 --]