RFC: Location for Device Tree Sources?

[Tom Rini]

On Fri, Aug 04, 2006 at 02:49:00PM +1000, Paul Mackerras wrote:
> Tom Rini writes:
> 
> > But "content requirements change" isn't the same as "left things out of
> > their tree".  It sounds, and I haven't seen the changes, so I'm not
> > certain that the meaning behind a field changed.  Something like that
> > should change the dt version.
> 
> I disagree.  Strongly.  The dt version relates to the representation
> of the tree, not its content.

But doesn't the representation include meaning?

> If we *have* to change the meaning of a property value in a particular
> node in an incompatible way, then we can do something such as adding
> another property to indicate what the interpretation of the first
> property value should be.  Usually it's possible to find a way around
> the problem without resorting to that, though.

Agreed.  Kicking myself for not being explicit enough :)

> >  New fields aren't a problem.  Changing
> > existing fields meaning in incompatible ways is a problem.
> 
> Only a minor, localized problem.  Nothing worth changing the whole dt
> version number for.

I'll rephrase what I said to what I think we all agree.  Changing
existing fields meanings in incompatible ways and not somehow allowing
that to still work (like by adding a flag so new trees are interpreted
one way, old trees are fixed-up or whatever) is a problem.

-- 
Tom Rini