On Tue, Oct 22, 2013 at 10:12:29PM +0200, 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. One
> possible solution that I can think of would be to use some kind of
> special marker within the compatible value defined by a binding that
> would be used to qualify it as unstable. Perhaps something as simple as
> a preceding exclamation mark (!) would do.
>
> gpio {
> compatible = "!foo-gpio";
> };
>
> The DT core code could look for that when matching device nodes to the
> list of compatible values supported by a driver and output a big warning
> message to make users aware of the fact that the binding may change. The
> driver could use the same marker in the OF device ID table to make it
> clear that it implements an experimental binding. Whenever a binding is
> deemed stable we can simply remove the marker from both the driver and
> the binding, as well as DTS files.
>From a technical POV this seems nice.
What does stable mean at this point? DTBs using the stable binding are
forever guaranteed compatibility with newer kernels? We really need to
define *exactly* what this implies for future support. More than likely,
most bindings will choose to stay experimental/testing indefinitely if
stable means a lifetime of ugly backward compatibility hacks.
-Matt
--
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
