Re: RFC: Location for Device Tree Sources?

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