Could the DTS experts look at this?

[David Gibson]

On Tue, Feb 12, 2008 at 05:47:23PM -0600, Timur Tabi wrote:
> David Gibson wrote:
> 
> > I can pretty much guarantee you that someone will find that
> > insufficient and want to expand the conditional representation.  This
> > way madness lies.
> 
> Then let them.  We can have version numbers associated with the conditional 
> expressions.  If they want to make more complex condition expressions, they can 
> bump the version number and define a spec and write code to parse it.
> 
> > No.  As Grant says, that's not what the version number is for.  It
> > represents the version of the encoding, not the content.  If you must
> > version the content (which you should try really hard to avoid) the
> > correct way is to add versioning properties to the root node.
> 
> And that's why I prefer updating the DTB format to allow attaching
> conditional expressions to nodes.  This would then necessitate
> bumping the version number.  Older U-Boots will reject this new DTB.
> We can also modify DTC to support conditional nodes, so that if a
> customer has an older U-Boot he can't update, he can use DTC to
> generate a V17 DTB that has the conditionals already processed.

Well, yes, folding conditionals into the format would mean a version
bump.  But I am *not* going to put conditionals into a dtb version,
and I'm pretty sure BenH and Paulus would also reject this notion.
It's simply not what the format is for.  dtbs are for parsing by the
kernel, giving a complete device representation.  If bootloaders and
other things also find them a useful input format, that's great, but
I'm not going to significantly extend the semantics just to support
other uses.

Now, if you want to define a new binary-level "meta-dtb" format,
designed for representing various conditionals or whatnot, which can
be processed into a final true dtb, go for it.  But a) if you base it
on the dtb format, make sure you use a different magic number so as
not to interfere with the actual dtbs version progression and b) I
think you'll find it's more trouble than it's worth, at least at this
stage (feel free to try to prove me wrong on this point, of course).

At present, I think the "meta-dtb" format which makes the most sense,
based on a balance between simplicity and flexibility is C, with one
or more dtb fragments embedded.  This can be done now (though if there
are libfdt extensions which would make this usage easier, please
suggest them - fdt_graft() is an obvious one).

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