[PATCH 8/9 V3] Add documentation for the new DTS language.

[Grant Likely]

On Mon, Mar 1, 2010 at 3:03 PM, Stephen Neuendorffer
<stephen.neuendorffer at xilinx.com> wrote:
> From: Scott Wood [mailto:scottwood at freescale.com]
>> 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.
>
> I agree, *IF* sequential operations are supported.
> But then you have a sequential programming language, not a structured
> data
> description.  I think this is a bad idea.

Indeed.  We've got lots of sequential programming languages.  I don't
want us to create for ourselves a new (and poorly implemented)
language.

>> I'd rather make them actually behave like immediate commands, though.
>
> But the question is, what is the semantics of the 'command language'
> (where ordering matters)
> from the 'structure language' (where ordering is unimportant).  My
> suggestion is to cleanly separate
> these two.  The only ordering that is defined is between sequential
> trees.  Within a sequential tree,
> only things which have the same meaning in any ordering of sub-nodes and
> properties should be allowed.

Yes, I think I agree with this.  The only ordering that matters is the
ordering of top level node redefinition blocks.

>> > Which brings up the question 'undeletion question'.  Can you do:
>> >
>> > d-label: delete(bar);
>> > delete(&d-label);
>>
>> I'd say no -- delete operates on data, not commands.
>
> This implies that data and commands are different.  And commands have to
> be ordered, which means that you have
> to keep the order of everything under a node, which chucks alot of the
> beauty of device trees, IMHO.

Right, well said.  I think the right thing to do is to avoid the
concept of commands entirely from the tree.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.