Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

[Grant Likely <grant.likely@secretlab.ca>]

Joel A Fernandes <agnel.joel@gmail.com> wrote:

>Hi Grant,
>
>On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely
><grant.likely@secretlab.ca> wrote:
>> I'm open to suggestions if anyone has any. I have not objections to a
>> fixup approach, but I'm not comfortable with anything that is fragile
>> to modifications to the fragment.
>
>I am fairly new to the DT world so please bear with me, but how about
>a method that resolves symbols the same way that the linux dynamic
>linker does when shared libraries are loaded?
>
>A separate table (similar to .PLT/GOT sections  in the ELF object
>format) could be created when the fragment is loaded, and the phandle
>references could be fixed to point to the table offsets during compile
>time. This table would be a second level indirection and the kernel
>would populate this table with the in-kernel values of the phandles
>that the dt fragment refers to.

That's an interesting idea that is worth exploring. That would make it possible to avoid a fixup stage, but it also means that any parsing code must know how to handle the got-like table. It won't be backwards compatible with existing tools. It also wouldn't easily support the case of firmware applying the overlay and passing the resulting tree to the kernel. Hmmm.... Not being backwards compatible at the data level is a big problem. I really want a method that can resolve back to the current data format or is a compatible extension of it.

>
>This might involve changes to the DT core, but as such, this method
>wouldn't suffer from the fragility problem of either base or fragment
>DT trees being modified.
>
>The table itself could be added to the tree by the compiler, and the
>phandles could point to it (fixed). such phandles could be marked for
>special handling to facilitate the 1-level indirection.

That's part of the problem. Property values are essentially anaonymous data. There is no mechanism currently for marking data such as indicate which data values are phandles. If there were then it would be a simple matter to find all the phandles and fix them up.

We could possibly add data type suppplementary properties to the tree to solve that problem. They would have to be optional for the base tree to retain backwards compatibility, but could be required on overlays.

g.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.