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

[Nicolas Pitre]

On Thu, 24 Oct 2013, David Woodhouse wrote:

> 
> >
> > On Thu, 2013-10-24 at 13:10 +0000, David Woodhouse wrote:
> >
> >> Note that you are not describing a normal "DT scenario" here. You are
> >> describing a case in which we screwed up
> >
> > AKA "real world"
> 
> No. Absolutely not. That was a screwup, and it needs to be *rare*. The
> excuses you present for it are crappy and uunacceptable.

Let's get real please.  It is just too easy for DT reviewers in their 
ivory tower to shot down submissions because the bindings are not to 
their liking.

The world out there is not stable.  Things change.  Hardware is revised 
all the time.  Software change to cope.  And even when the hardware is 
stable, new software solutions come about to improve things.  That's the 
point of _soft_ware, isn't it?  Flexibility is needed in order to scale.

"DT only describe the hardware" is often brought up as if that was the 
ultimate argument for its "stability".  But descriptions, even hardware 
descriptions, may be subjective i.e. two humans might describe it 
differently.  Incidentally DT bindings are created by humans and are 
therefore imperfect and suboptimal most of the time.

We used to have very lenient reviews on new DT bindings.  Sure some of 
them were bad.  The recent reaction to that was to go 180 degrees and 
accept only near perfect bindings.  But the cure is now hurting more 
than the initial problem.

Sure, the world would be so much better if DT bindings could be optimal 
on the first shot.  But asking that DT bindings remain stable when the 
world around them is not is asking for the impossible.

So IMHO the failure with DT right now is actually the expectations that 
come with it.  Those expectations are not realistic.

Special cases are the norm, whether you like it or not.  In fact we all 
hate special cases because they make what would otherwise be a very 
straight forward and elegant process rather messy.  This is why a 
process needs to concern itself with special cases since this is where a 
process is even more helpful.

So instead of trying to enforce even more stability in the DT bindings 
with stricter rules, I think that the process should instead concern 
itself with better ways to _allow_ and _facilitate_ binding updates.  
This is much more likely to scale, and result in a better system in the 
end.

And since there is so many changes one can bring to ultimately describe 
some piece of hardware, the DT bindings will naturally reach a stable 
state eventually. But that cannot be known in advance when that will be.


Nicolas