Re: devicetree repository separation/migration

[Warner Losh <wlosh-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org>]

On Feb 20, 2014, at 4:38 AM, Grant Likely wrote:

> 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.

I wasn't in Edinburgh...  Was this at the binary level or at the source level? I'm thinking specifically about the move to cpp in the back of my mind...

> 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.

Versioning here wouldn't save you either...

> 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.

You could have a property like linux,version-min="3.22" if that becomes an issue...

Warner

--
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