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

[David Gibson]

On Sat, Oct 16, 2010 at 12:57:21PM -0600, Grant Likely wrote:
> 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:
[snip]
> >> > 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

Yes, I noticed that :)

> clarify my position.  Ordering is still restricted to the top level
> what I'm suggesting.  For example, the following would be legal:

[snip]
> 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.

Right, I understand the model and, yes, it's simple enough to
implement.  I'm just not sure if it's a good idea - allowing the
replace versus extend flag to be per sub-tree rather than per toplevel
tree is a step up in model complexity, and hence a step down in
obviousness.  I'm not yet sure if it's worth it (or perhaps rather, if
there's a cleaner alternative).

> >> > 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.

Ok.

-- 
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