Re: The future of DT binding maintainership

From: Tomasz Figa
Date: Mon Jul 22 2013 - 16:09:20 EST


Hi Alison,

On Monday 22 of July 2013 19:59:25 Chaiken, Alison wrote:
> Grant Likely wrote:
> > Another thing discussed is that we need to start validating DT schema
> > with an extension to dtc.
> Is there a schema out there in the wild that exemplifies what you mean?

Not really. The format of schemas is currently in design stage. I'm
currently rethinking some details of what I have in my mind. Give me some
more time and I will post an RFC to the ML with all that written down.

> > Tomasz Figa has volunteered to do this work and has support from his
> > employer
> That's great news.
>
> > to have is that the DT schema will get checked as part of the dts
> > build
> > process so that any DT file that doesn't match the documented schema
> > will get flagged, and that the schema files will be human readable and
> > will double as documentation.
>
> No doubt DTS files are already the best documentation available for many
> targets. The vendor's technical reference manual describes how the
> hardware is supposed to work, but the DTS describes what actually does.
> Any errata that the vendor issues subsequent to publication of the
> TRM must be reflected in DTS, after all.

I'm not sure about this. Device tree should describe what hardware it is,
not how it works, unless it is really necessary.

> The schema-check idea reminds me of the W3C HTML validators:
>
> http://validator.w3.org/
>
> Since device-tree source looks a bit like XML (or maybe more like JSON),
> will be the schemas be similar in spirit to DTDs, and is it helpful to
> think of the validator in this spirit? Or will the checker be more
> like "gcc -Wall", since it will be invoked by a compiler?

My idea is to implement compile time verification in dtc, so I guess it
will be more like the latter. Since dts is what dtc can already parse, my
plan is to keep the schemas in spirit to dts, just modifying/extending it
to allow specifying bindings with them, rather than static values.

Best regards,
Tomasz

--
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/