Re: devicetree repository separation/migration

On Thu, Feb 20, 2014 at 3:38 AM, Grant Likely [off-list ref] wrote:

On Wed, 19 Feb 2014 13:20:15 -0800, Olof Johansson [off-list ref] wrote:

quoted

On Wed, Feb 19, 2014 at 1:12 PM, Rob Herring [off-list ref] wrote:

quoted

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.

That's true. For the most part this should work well as we enable IP
for DT, since before then we'll fall back on old configuration ways.
Where it gets complicated is if we deprecate a whole binding and make
a new one, or if we change the meaning of properties. Due to the ABI
properties, we shouldn't be doing the latter anyway. The former is
obviously a problem but we might just have to live with it. I don't
think we're likely to hit it much in reality once bindings stabilize
-- main case would be if we want to rewrite some of the very old and
maybe not so good bindings (like the mtd driver binding that the at91
guys came up with early). But in reality we're likely to just stick
with them and not bother.

So, yes, it does change the formality but in reality I don't expect
that much of a difference.

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.

Nope.

This is an issue for new bindings, only when a binding is getting

s/is/isn't/, which I think was your intent.

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.

Yes, I think I said the same thing above in my reply now. :-)

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.

This might work with the mirroring case, but it'll get awkward if we
have completely separate repos and thus potentially separate
reviewers/approvers, if things get additional scrutiny between the
staging phase in the kernel and when it gets merged upstream,
especially if the DTS has already been moved out. I'm not quite sure
how that would work, really.

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