RFC: Location for Device Tree Sources?
trini at kernel.crashing.org
Sat Aug 5 03:54:18 EST 2006
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.
More information about the Linuxppc-dev