RFC: Location for Device Tree Sources?

[Milton Miller]

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:
> > On Wed, 2006-08-02 at 13:21, Tom Rini wrote:
> > 
> > > 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..
> > > 
> > > > > 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.  
...
> > Same (DTS) format
> > both before and after the IRQ changes.
> > 
> > What have I missed here?
> 
> Matthew said:
> > 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