On Tue, Nov 29, 2016 at 10:50:53AM +0000, Phil Elwell wrote: > On 29/11/2016 10:39, Pantelis Antoniou wrote: > > Hi Phil, > > > >> On Nov 29, 2016, at 12:32 , Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote: > >> > >> On 29/11/2016 02:11, David Gibson wrote: > >>> On Mon, Nov 28, 2016 at 12:24:20PM +0000, Phil Elwell wrote: > >>>> On 28/11/2016 12:10, Pantelis Antoniou wrote: > >>>>> For plugins we need the __symbols__ node to support stacked overlays, i.e. > >>>>> overlays referring label that were introduced by a previous overlay. > >>>> Although it is arguably useful to be able to refer to symbols created by > >>>> one overlay from within another, do we really want all symbols to be > >>>> global? Isn't there a call for a new syntax or usage pattern to indicate > >>>> either that a symbol should be local to the overlay or, my preferred > >>>> option, global? > >>> So, this is back to a design question about the overlay format. As > >>> noted in the initial discussions about possible "connector" formats, I > >>> think we will want some sort of local symbols. But the current > >>> overlay format with all global symbols is out there and we need to > >>> support it. > >> The overlay format we have does not dictate the scope of the symbols. > >> > >> In all implementations I know of - the Raspberry Pi loader, the current > >> Linux kernel, the latest dtc patch set - there is a completely > >> asymmetric relationship between the base DTB and an overlay: > >> * the base DTB exports __symbols__ to resolve the overlays unresolved > >> label references, as recorded by the __fixups__ node > >> * the overlay's phandles are renumbered so as not to clash with the base > >> tree using the __local_fixups__ > >> * the contents of the __overlay__ nodes are applied to the base tree, as > >> directed by the "target" or "target-path” properties > >> > > Yes > > > >> The __symbols__ node of the overlay is ignored and discarded. The > >> __fixups__ and __local_fixups__ in the base DTB (if present - the RPi > >> dtc only generates them for /plugins/) are ignored. > >> > > That was a limitation that no-longer applies. Overlay symbols can be added > > to the base tree symbol list with a small patch I have already posted. > The fact that they can doesn't mean they necessarily should. They should - at least as long as we're using this simple overlay format. What else would you do with them? If they're not merged, they're useless in the overlay. > > > >> In the set of RPi overlays only one exports a global symbol, which it > >> achieves with an overlay aimed at target-path = "/__symbols__" that adds > >> a new symbol (in this case "i2c_gpio"). > >> > >> If the __symbols__ in an overlay are automatically merged with the base > >> symbols, that is a significant change in semantics which needs to be > >> discussed. > >> > > You no longer need to do this anymore. Hope this helps :) > > Not really, no. With the current scheme we have control over the scope, > but now there is none. You really don't, symbols were always global. > > How does your patch handle duplicate symbols? > > Phil -- 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
