Re: The future of DT binding maintainership

From: Stephen Warren
Date: Thu Jul 25 2013 - 13:46:23 EST


On 07/24/2013 07:11 AM, Grant Likely wrote:
> On Sat, 20 Jul 2013 15:49:21 +0200, Tomasz Figa <tomasz.figa@xxxxxxxxx> wrote:
...
>> From remaining questions I remember:
>> - How should we mark bindings as staging and stable? (i.e.
>> documentation/schema files in different folders or something else?)
>
> I think having a different folder for staged bindings is going to be the
> most managable. The other option would be a tag in the file indicating
> that it is stable, but I suspect that will require more work in the long
> run. At least with a staging directory you can tell at a glance which
> bindings are in draft form. Any bindings used from the staging directory
> should trigger a warning from DTC, but we probably want to consolidate
> all 'staging' binding warnings into a single message so that dtc output
> doesn't get too chatty.
>
> Once a binding is moved into the stable directory, only backwards
> compatible changes should be allowed.

Is the following scenario useful to consider

* A minimal DT binding is initially created to represent the most basic
features of a device. This graduates quickly to being marked stable.

* The full feature-set of the device needs to be exposed later. This
involves making backwards-compatible changes to the binding. Those
changes may initially be very tentative, since they're more complex.

This implies to me that we either need to mark specific properties or
parts of a binding as stable, and part as tentative. Does using separate
directories for this make sense, or should we put markup into the
binding definition itself?

I suppose we could consider bindings/tentative/foo/bar.txt as
automatically inheriting-from/extending bindings/stable/foo/bar.txt.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/