On Tue, 22 Oct 2013, Thierry Reding wrote: > On Tue, Oct 22, 2013 at 01:42:48PM -0400, Nicolas Pitre wrote: > > On Tue, 22 Oct 2013, Matt Porter wrote: > > > > > DT has many benefits. It would be great to leverage them as long as it > > > doesn't interfere with the rate of change and willingness to evolve code > > > that's always been the strength of the kernel process. That strength is > > > too valuable to trade away for the "DT as ABI" vision. > > > > Amen. This is the best statement I've read about DT so far. > > > > Having "stable" DT bindings is just a dream. Experience so far is > > showing that this is neither practical nor realistic. > > > > The unstructured free-for-all approach isn't good either. Some > > compromise between the two extremes needs to be found. > > I agree. I think we need an easy way to mark bindings as unstable. No, that's not a solution. It is fairly easy to qualify a small set of bindings as "stable" for interoperability purpose (e.g. for qemu/kvm). But for the vast majority it is very hard to decide when a particular binding has reached stability. By definition, a binding may be considered "stable" only after seeing no change for a reasonable period of time being tested and used. So stability may simply not be a criterion for upstream merging. I think it is best to establish any process around DT assuming no strong binding stability. Eventually the DT binding update frequency will converge to zero while the kernel will continue to be developed. But the DTB for a particular hardware might have to change from time to time. Nicolas -- 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
