[Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/27/2013 12:36 PM, Tomasz Figa wrote:
> On Saturday 27 of July 2013 12:24:24 Arend van Spriel wrote:
>> On 07/27/2013 11:51 AM, Tomasz Figa wrote:
>>> On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:
>>>> On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:
>>>>> Long term, final goal is likely to be close to what Russell is
>>>>> saying
>>>>
>>>> Why is this a long term goal? Start today.
>>>>
>>>>> -- nothing should go into the kernel tree unless the binding is in a
>>>>> fully stable state. However, we have a transitional period between
>>>>> now
>>>>> and then, and even when we're at the final state there will be need
>>>>> to
>>>>> have some sort of sandbox for development and test of future
>>>>> bindings.
>>>>
>>>> Why not just set up a git tree right away?
>>>>
>>>>> Dealing with all that, as well as the actual process for locking in
>>>>> bindings, is what needs to be sorted out.
>>>>>
>>>>> I think we're all in agreement that bindings that change over time
>>>>> are
>>>>> nothing but pain, but we're arguing that in circles anyway.
>>>>
>>>> No.
>>>>
>>>> I keep saying, the bindings must be stable ABI, *today*.
>>>>
>>>> You keep saying, maybe later, but until then we will make things up
>>>> as
>>>> we go along.
>>>
>>> We have currently a lot of broken bindings, because people didn't know
>>> how to define ones and those they defined have not been properly
>>> reviewed. Do you really want such broken ABI in the kernel?
>>>
>>> Sure, there are many existing bindings that can be just made stable
>>> and
>>> well they probably are already de facto stable. This is mostly about
>>> subsystem bindings and whatever already has many users, both made them
>>> get more thought when designing and more review before merging.
>>>
>>> Still, a lot of device and platform-specific bindings are simply
>>> broken. Take max8925 backlight driver, that Olof started this whole
>>> discussion with, as an example. We need to sort them out before they
>>> can be stabilized.
>>
>> That is a nice summary of how we got from null to now and Richard seems
>> to be simply saying: let's stop mucking about and make this a project
>> with a well-defined process of dealing with staging and stable bindings
>> and keep stable bindings stable. Whether it should be within the kernel
>> repo as a separate subsystem or in an entire different repo is a trivial
>> decision, but still a decision that needs to be made.
>
> Yes, basically that's our current situation.
>
> Still, I would disagree about the decision being trivial, as each choice
> will have further, and likely pretty significant, consequences on binding
> maintenance, submission, review and for dependent things, like drivers or
> platforms using such bindings. This needs to be discussed enough.
>
>> Apart from stable DT bindings I would love to see a DT compiler that
>> that next to DT syntax detects mistakes in properties used for the
>> selfish reason that I spent hours debugging regulator code, because I
>> typed vmmc_supply iso vmmc-supply. I did not go through all the
>> bindings, but this may require a more formal description so it could be
>> compiled/read in the DT compiler.
>
> This bothered me as well and that's why I'm working on this. I still can't
> get myself to write a very long mail (I'm more a coder than writer...)
> about the whole idea, my proposal of how it could look and problems we
> need to solve, but I'll try better this evening.

Let's see how many people go and scream if I say this: Too bad .dts 
files are not done using XML format as DT bindings could be described 
using XML Schema.

Regards,
Arend