Hi Joel,

On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote:

Hi Grant,

On Mon, Nov 5, 2012 at 5:58 PM, Grant Likely [off-list ref] wrote:

quoted

Joel A Fernandes [off-list ref] wrote:

quoted

Hi Grant,

On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely
[off-list ref] wrote:

quoted

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?

To be honest here, we are discussing a new object format. 
There are a few twists IMO.

a) We definitely, absolutely, don't want to introduce anything that will
risk compatibility with devices already out there. The binary format
for device trees that don't need the dynamic resolution features we're
talking about here, should be be usable for those older devices.

b) Device tree is flexible enough to store the additional data in it's own
node format. So we shouldn't have any kind of binary data tacked on; this
ties with a) - make sure that the binary format doesn't change.

c) There is no need (at least AFAIKT) of having any other resolution type
than a phandle of a node.

d) Finally, for some use-cases the problem is simplified by not having
all the features of a true dynamic linker. For example for the capebus
case the 'base' DTS won't have any references to any fragments. It is only
the fragments that have unresolved references and only to the 'base' DTS.

quoted

quoted

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.

I'm fine with this.

Thanks and Regards,

Joel

Regards

-- Pantelis