Re: devicetree repository separation/migration

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Wed, 19 Feb 2014 13:20:15 -0800, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
> On Wed, Feb 19, 2014 at 1:12 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > One way to minimize the inconvenience is keep versioning and dev
> > cycles in sync with the kernel. We could also start doing things to
> > align the kernel workflow with how things will work when we do have a
> > separate repository.
> 
> I don't think aligning development cycles is what we want most here it
> might be useful for us in Linux but it'll make things difficult for
> other projects since they're not aware of our release cycles. The
> device tree bindings and DT contents in that repo should be "always
> stable", i.e. no merge window / rc concept. As soon as something goes
> in it's live, and from then out only fixes to the DTS files (or
> appending the binding).
> 
> For example, I don't want to have to track two trees to test against
> -- I'll want to keep one repo of the very latest DT files and always
> use those to boot any and all boards.

This approach does have the subtle side effect that differs from what we
discussed in Edinburgh.  We've talked about always being able to boot a
new kernel on an old devicetree, but not a new devicetree on an old
kernel. With a separate board database repo we are going to hit both
cases. At least to a limited extent we're going to need older kernels
booting with the latest devicetree, and we'll need some rules about how
that gets applied.

The alternative is that binding changes land in .dts files after a
kernel release, and I don't think we want that situation at all.

This is an issue for new bindings, only when a binding is getting
extended or replaced. If the change is merely adding new properties then
there shouldn't be a problem (the old kernel will ignore the new
properties). If it removes properties or creates a new compatible string
(dropping the one supported by an older kernel) then it won't boot.

Ultimately this is probably the right thing to do, but it will be
difficult. Keeping a staging process for new bindings in lock step
with the kernel is probably the way to mitigate this.

g.
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html