Re: [PATCH 0/7] of: overlay: Add support for export-symbols node feature

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

 



On 10/12/24 15:11, Herve Codina wrote:
Hi Ayush,

On Tue, 10 Dec 2024 14:52:22 +0530
Ayush Singh <ayush@xxxxxxxxxxxxxxx> wrote:

...

What is the reason for not using symbols directly as described here [3]?

I do like this approach since it does not pollute the global symbols.
Just want to know if there are any other reasons for it.


Modifying the __symbols__ node at runtime (adding / removing properties in
it) exposes memory leaks if __symbols__ already exist in the live DT.
This __symbols__ node exist if the dtb was compiled with '-@' or if you
chain the overlay (i.e. __symbols__ node created by the first overlay).

Yeah, that is a problem, specially in a setup which might involve hot-plugging.


I think also that some conflicts can appears. What happens if you want to
add a new label but this label is already present for some other purpose?

I do not think that actually is a problem. As described in the original patch [0], the symbol and connector overlay is supposed to be applied as a group (overwriting any conflicting symbols in the process).

The reason why this is not a problem is that `__symbols__` are only used to resolve the phandles (overlays do not support path references yet), but do not really have a purpose in the livetree (at least far as I know, but I can be wrong).


Best regards,
Hervé

[0]: https://lore.kernel.org/lkml/20240702164403.29067-1-afd@xxxxxx/

Ayush Singh




[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