Hi Phil, > On Nov 29, 2016, at 12:50 , Phil Elwell <phil@xxxxxxxxxxxxxxx> 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. >> >>> 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. > Manually adding symbols by targeting __symbols__ is just bad. There is absolutely no guarantee that the symbol/fixup node(s) will still be there in following iterations of the patches. I am thinking of parsing them, recording the information in kernel structures and then deleting them altogether. > How does your patch handle duplicate symbols? > It doesn’t. Having duplicate global symbols is bad. It appears you want scoping rules instead. Care to paste a concrete example? > Phil Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
