From: Milton Miller <hidden> Date: 2006-08-03 09:45:36
On Wed Aug 2 2006 01:57:28 PM CDT, Tom Rini wrote:
On Wed, Aug 02, 2006 at 01:23:08PM -0500, Jon Loeliger wrote:
quoted
On Wed, 2006-08-02 at 13:21, Tom Rini wrote:
quoted
Yes, as I said, I'm not totally sure we're at the stable point right
now, but I think that we are. I'll add that maybe we need to think
about API changes and DTS format versions. To quote from my post..
quoted
quoted
X bugs) or a change that requires a dts version bump.
Now it sounds like the IRQ thing was an "Oops, we should have changed
the dts version" and bailed, noting what is wrong with the dts.
This confuses me.
...
quoted
Same (DTS) format
both before and after the IRQ changes.
What have I missed here?
Matthew said:
quoted
The sandpoint (as far as I know) does not have a stable DTS. So in this
case including the DTS in the kernel would reduce confusion. The same
could be said for other boards where the DTS needed to be changed for
the IRQ rework. The old DTS will no longer boot the new kernels. I'm not
sure how much longer we will run into this problem though.
Now, if we've had to change the contents of the DTS because of a kernel
change, I'd say the DTS format changed as when I say format I mean not
only layout and naming, but what the contents are supposed to contain.
And, so it's clear, I don't know if we're at the very stable format
(names/layout/content means...), but when we are at that point, what
Matthew noted should, IMHO, be a graceful (ie explained in the panic()
or something) death.
And, so it's clear, I think (and hope!) we all agree on that last part,
once we hit stability.
I don't think we need to bump the dt version every time we make a tree
content requirements change. We need to bump when we add or
change fields in the struct header, change internal layout, or change how
we pass information through the tree. Certianly not because someone
left things out of their tree.
If we bump every time we check some new property, then the tools will
always be producing the wrong version and/or we will end up with trees
that claim they are good for some broad range that is really incompatable.
That being said, I haven't looked at what is now required. If we were to
eexpect some shim or preeparsing code to fixup existing trees then that
might warrant a version number beng assigned, if such information is not
readily determined by scanning the tree.
milton
On Thu, Aug 03, 2006 at 04:32:33AM -0500, Milton Miller wrote:
I don't think we need to bump the dt version every time we make a tree
content requirements change. We need to bump when we add or
change fields in the struct header, change internal layout, or change how
we pass information through the tree. Certianly not because someone
left things out of their tree.
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. New fields aren't a problem. Changing
existing fields meaning in incompatible ways is a problem.
--
Tom Rini
From: Milton Miller <hidden> Date: 2006-08-03 16:30:45
On Aug 3, 2006, at 8:54 AM, Tom Rini wrote:
On Thu, Aug 03, 2006 at 04:32:33AM -0500, Milton Miller wrote:
quoted
I don't think we need to bump the dt version every time we make a tree
content requirements change. We need to bump when we add or
change fields in the struct header, change internal layout, or change
how
we pass information through the tree. Certianly not because someone
left things out of their tree.
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. New fields aren't a problem. Changing
existing fields meaning in incompatible ways is a problem.
Agreed. I too haven't looked at the change, but thought it was the
former.
From: Paul Mackerras <hidden> Date: 2006-08-04 04:49:00
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.
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.
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.
Paul.
On Fri, Aug 04, 2006 at 02:49:00PM +1000, Paul Mackerras wrote:
Tom Rini writes:
quoted
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 :)
quoted
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
From: Paul Mackerras <hidden> Date: 2006-08-04 23:29:20
Tom Rini writes:
But doesn't the representation include meaning?
No, in the sense that the device-tree representation doesn't define
what meaning or interpretation is to be given to particular node and
property names or to particular property values.
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.
Yes it's a problem. Not one that we want to solve by changing the dt
version number, though.
Paul.