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.
Thierry
Attachment:
pgp78zCsEj9mb.pgp
Description: PGP signature
