Re: [Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

On Tue, Oct 22, 2013 at 04:41:23PM -0400, Nicolas Pitre wrote:
[...]
> 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.

A stable ABI certainly has its advantages in my opinion. That's why I'm
convinced that we should try and accomodate for both options. We should
try to come up with a good binding to begin with, as much is clear. But
there's little point in reviewing it to death because any number of
reviewers are unlikely to consider every single possible use-case.

So I propose that we mark such bindings unstable to allow us to put them
through some real world testing in mainline to find out if they work in
practice or not. If they do work reasonably well for a large number of
use-cases, we can decide to mark them stable, at which point they can
only be modified in a backwards-compatible way. That still gives us the
freedom to supersede it by a better binding if that ever becomes
necessary.

The reason why I propose to explicitly mark bindings unstable rather
than the other way around is that I still have hope that we'll reach
some level of stability eventually. It will probably still need some
time because most of us are learning as we go and just don't have the
experience to get things right from the start.

Having some visual marker, such as the exclamation mark I proposed, in
the compatible value is irritating enough to make it clear that it's not
"good". That's an incentive for people to actively work on making it
good or giving it the necessary testing to be able to declare it good.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]