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

[Stephen Neuendorffer]

> -----Original Message-----
> From: Scott Wood [mailto:scottwood at freescale.com]
> Sent: Monday, March 01, 2010 1:06 PM
> To: Stephen Neuendorffer
> Cc: grant.likely at secretlab.ca; Yoder Stuart-B08248; Wood Scott-B07421;
devicetree-discuss at ozlabs.org;
> John Williams; Jeremy Kerr
> Subject: Re: [PATCH 8/9 V3] Add documentation for the new DTS
language.
> 
> Stephen Neuendorffer wrote:
> > One thing I've seen in the past is that there is a sequentialization
question in this, which becomes
> > more apparent once deletion is allowed.
> >
> > First off, my assumption is that each node name is always unique in
a tree, even when overrides are
> allowed.
> > Otherwise the sub-node and property ordering becomes important.
> >
> > foo {
> > 	bar = 2;
> > 	bar = 3; // Illegal
> > } ;
> >
> >
> > foo {
> > 	bar = 2;
> > }
> > foo {
> > 	bar = 3; // Legal
> > };
> >
> >
> > So, essentially, sequentialization of operation is forced by the
concatenation of trees.
> 
> 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.

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.

> What are the problems with supporting this?

Mainly the fact that properties and sub-nodes have a semantically
important ordering.
This can be done, but it's not as clean.

> > foo {
> > 	bar-label: bar = 2;
> > }
> > delete(&bar-label);  // Legal.
> > foo {
> > 	bar-label: bar = 4;  // Legal, even though previously deleted
> > }
> 
> Is it legal to reuse the label, even though it sort of points to the
same spot?
> 
> If you don't reuse the label, but bar is redefined, where does
bar-label point?
> 
> Do all labels to nodes in separate trees that end up referring to the
same node
> in the final tree have the same phandle?  Are they interchangeable in
subsequent
> delete commands?

I think these are all good questions which someone who has a much better
grasp of the
intention of labels probably has to answer.  Since they are somewhat
separate from the point
I was trying to show with the example (and as Grant replied, my examples
are perhaps poorly
formed anyway), I'm just going to duck them.

> > One trick is that the below is problematic, or at least hard to
verify statically.
> >
> > foo {
> > 	delete(&bar-label); // Legal.
> > 	delete(bar); // May or may not be Illegal, since don't know what
bar-label references
> > }
> 
> That raises the question of whether it's legal to delete things that
aren't
> there.  There may be cases where a dts fragment A doesn't know whether
fragment
> B will have defined something, and fragment A wants to make sure it
ends up
> undefined one way or another.

Yes...  A very good question.  I would say that it could probably be
either way
without screwing things up too badly.

> > So, to syntax: the sequentialization property may be more
syntactically obvious if deletion
> resembles
> > setting a property or node like:
> >
> >  ^bar
> >  !bar
> > or even
> >   bar = !;
> >   bar !;
> 
> What specifically is made more obvious?  Using symbols rather than
names seems
> more cryptic to me.
> 
> Only the "bar = !" form seems to clearly indicate that, for the
purposes of this
> particular tree, you're assigning some special placeholder to bar
rather than
> performing an immediate action.  That could just as well be done with
something
> like "bar = /delete-prop/".
> 
> 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.

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

Steve


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.