Proposal: new device-tree syntax and semantics for extending information from included dts files

[Grant Likely]

On Sat, Oct 16, 2010 at 1:02 AM, David Gibson
<david at gibson.dropbear.id.au> wrote:
> On Wed, Oct 13, 2010 at 10:54:13PM -0600, Grant Likely wrote:
>> On Thu, Oct 14, 2010 at 02:48:21PM +1100, David Gibson wrote:
>> > On Wed, Oct 13, 2010 at 07:40:36PM -0600, Grant Likely wrote:
>> > > &some-node {
>> > >   node-to-remove /remove/;
>> > >
>> > >   node-to-replace /remove/;
>> > >   node-to-replace { prop = "blah"; };
>> > > };
>> > >
>> > > I don't like this one because it implies ordering between the first
>> > > and second 'node-to-replace' definitions, and to this point the syntax
>> > > has not imposed any order assumptions.
>> >
>> > Hrm.  Well, more precisely I was thinking of:
>> >
>> > &{/some/node} /remove/;
>> >
>> > &{/some/node} {
>> >     new-contents;
>> > };
>> >
>> > Since I thought the original proposal was that these node /replace/,
>> > /extend/ whatnot were only valid at the top level (for the reasons
>> > we've discussed on previous occasions).
>>
>> Hmmm, I thought we had figured out how to solve those issues by using
>> a flag to indicate that a node or property "masks out" the same node
>> or property in a preceding top-level tree.
>
> Um.. I don't follow.

Sorry, I was thinking about a different aspect of the problem and I
didn't make that clear.

>
>> > We do already have ordering
>> > amongst the top level items, since the last one wins.
>>
>> Right, but the ordering has been explicitly restricted to the top
>> level trees using the "stack of overlays" conceptual model.
>
> Right, my point exactly.  I'm suggesting we keep it restricted to the
> top level by only allowing these replace/remove operators (whatever
> they look like) at the top level.

Sounds like we're having an impedance mismatch.  Let me try to
clarify my position.  Ordering is still restricted to the top level
what I'm suggesting.  For example, the following would be legal:

	/ {
		node {
			prop;
		};
	};

	/{
		/trim-node/ node;
	};

But this would be illegal (enforced by dtc):

	/{
		node {
			prop;
		};
		/trim-node/ node;
	};

And this would also be illegal (also enforced):

	/ {
		node {
			prop;
		};
	};

	/{
		/trim-node/ node;
		node {
			newprop;
		};
	};

The model I'm suggesting is that each top level tree is fully
constructed before being merged into the preceding tree.  Additional
nodes and properties are easy to understand and it works already.
I'm suggesting that the above illegal examples are exactly the same as
the following illegal example:

	/ {
		node {
			prop;
		};
		node {
			another-prop;
		};
	};

It is illegal because the node is defined twice in the same block.  If
it were allowed, then it would raise the question of which node gets
processed first, and we have explicitly decided not to support that
model.

The removal or replacement of nodes is exactly the same.  However,
instead of adding to a node, we set a flag in the new node stating
that it replaces the node in the preceding tree.  Or in the case of
removal, we set a flag that states the node in the preceding tree is
to be removed without a replacement.

In terms of implementation this should be straight forward.  In the
merge_nodes function, check the new node for a replace/remove flag,
and if it is set then remove/replace the old node instead of merging
with the new.  This can probably be performed in the
while(new_node->children) loop.

This is what I was talking about when I mentioned using a flag
earlier.  The /*-node/ keyword could set a flag in the node structure
so that merge_nodes handles the operation correctly when merging the
trees.

>
>> > Now, if using
>> > labels rather than full paths it does get a bit curlier on the
>> > implementation side.  But I don't think it would be that hard to make
>> > labels stick around attached to a path, even when the path itself is
>> > removed.
>>
>> Ah right, the issue here was that a previous tree could be holding a
>> label reference that gets deleted in an overlay.  And there are
>> questions about what happens if a label is removed and then the same
>> label attached to a new node, specifically because labels aren't
>> resolved until after the trees are fully parsed.  (let me know if I'm
>> remembering incorrectly).  I think this is solvable though, but we're
>> going to need to define the semantics.
>>
>> I need to review the details though.  I can't remember all the ways
>> that the code handles label resolution.
>
> Right.  Having labels move around seriously muddies the waters, since
> the whole idea of labels is to unambiguously refer to a node.  I think
> the sanest thing is to prohibit duplicate labels, even if the labelled
> nodes have been removed between the duplicate declarations.  In the
> later stages of processing, then, referring to a deleted label would
> be detectable and trigger an error at that point.

Fair enough.  I can agree to that constraint.  It can be revisited
again if it is too restrictive, and it is easier to relax
restrictions later than it is to add new restrictions at a later date.

g.