On Mon, Mar 01, 2010 at 07:16:57PM -0700, Grant Likely wrote:

On Mon, Mar 1, 2010 at 7:10 PM, Grant Likely [off-list ref] wrote:

quoted

On Mon, Mar 1, 2010 at 6:19 PM, David Gibson
[off-list ref] wrote:

quoted

On Mon, Mar 01, 2010 at 04:50:48PM -0600, Scott Wood wrote:

quoted

Grant Likely wrote:

quoted

On Mon, Mar 1, 2010 at 2:06 PM, Scott Wood [off-list ref] wrote:

quoted

Hmm, I'd think it would be useful to e.g. include a template and
subsequently modify it within the same node, rather than a more verbose and
error-prone process of referencing labels later.

If sequential operations within a tree are supported, I'm not sure that
there's any remaining need for separate top-level trees -- you could express
the same thing as top-level property/node redefinitions.

What are the problems with supporting this?

The main problem is that it doesn't fit the use cases I need to solve.
I need to start with a 'stock' or 'vanilla' tree, and then add into
it board details.  ie. lay down a generic MPC5200 tree (include a .dts
file), and then fill it in with i2c and spi devices.  Or include the
.dts file generated by the XIlinx FPGA toolchain, and then populate it
with board details.  Sequential operations within the tree doesn't do
anything to support this use case because the board level fixups will
be applied all over the tree.

To reverse the question, what is the use case that is best solved with
sequential operations within the root tree?

The case I had in mind was having includable templates for fragments
of the tree, rather than starting with a generic full tree.  Though
I'd probably end up wanting things like template arguments and math
as well (is any existing macro language going to do cell
arithmetic?),

m4 can do arithmetic, but it's pretty hideous.  But I still have
allowing expressions as a reasonable extension within dtc itself.
Macros or templates with parameters raise a lot more complex issues.

[snip]

quoted

quoted

quoted

If you don't reuse the label, but bar is redefined, where does bar-label
point?

It doesn't point to anything because when a property is deleted, the
label also goes away.

Is it the same way with node labels?

Yes, node labels are attached to the node, so if the node is removed,
so is the label.

quoted

What happens to previous
references?  Is it detected by dtc, or does a bad phandle/path stick
around to be found at runtime?  And what if the node is added back?

References aren't resolved until the whole tree is built.  So
references will always resolve to the *last* definition of a label,
and if the last "definition" is an undefinition / deletion, then the
references will fail to resolve and give an error.

...except for when processing node redefinitions by label in the current patch.

In fact, I think this has to be the case, otherwise it would be
possible to create circular references in node redefiniton.

Ah, yes.  Node redefinition references act in order with the labels.
Which is a potentially nasty inconsistency.  Ugh.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson