Re: [PATCH v10 3/4] dtc: Plugin and fixup support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux