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@xxxxxxxxx> 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.
>> This is important if the overlay is for an add-on board which might
>> have several instances plugged into different sockets on the base
>> system.
>>
>> But Phil does bring up an interesting use case. If the add-on board
>> ("level one add-on") in turn has a socket that an additional board
>> ("level two add-on") can be plugged into, then the level two add-on
>> overlay might have a need to reference a symbol from the overlay
>> for the level one add-on. And since there may be multiple level one
>> add-on cards in the system, the overlay for each of the level one
>> add-ons would need to export its symbols in a name space only
>> visible to the level two add-on plugged into that specific level
>> on add-on.
>
> That use case adds a further level of complexity. Should it come to it, I
> hope an inability to solve the problem posed by this advanced usage won't
> prevent a solution to a simpler problem from being accepted.
--
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
