On Feb 20, 2014, at 4:38 AM, Grant Likely wrote: > On Wed, 19 Feb 2014 13:20:15 -0800, Olof Johansson <olof@xxxxxxxxx> wrote: >> On Wed, Feb 19, 2014 at 1:12 PM, Rob Herring <robherring2@xxxxxxxxx> 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" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
