Hi Grant, On Mon, Nov 5, 2012 at 5:58 PM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: > > > Joel A Fernandes <agnel.joel@xxxxxxxxx> wrote: > >>Hi Grant, >> >>On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely >><grant.likely@xxxxxxxxxxxx> 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. > Is it meaningful or feasible to make the table a part of the tree structure itself? the table would initially be empty. If I'm right, this is how the GOT tables in ELF objects that refer to unresolved symbols in shared libraries are implemented as well, they are a part of the object and are loaded into memory and fixed up. If the table is a part of the DT data, the tools would then be able to parse such a tree. We could enforce that the got-like tree would strictly follow a predefined format. Something along these lines would also avoid the need for a tree fix up. Do you think this reduces the difficulty of backward compatibility with the parsing tools and firmware loading? >> >>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. > Sure, so if we add data type supplementary properties to the tree to indicate the data type as "indirect phandle", then kernel could refer to the index in the got-like table to fetch the actual phandle address (1-level of indirection), instead of directly using the address in the data field. Thanks and Regards, Joel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
