linux-kernel - Re: The future of DT binding maintainership

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1925583.R0td2pS6as@flatron>
Date:	Mon, 22 Jul 2013 22:09:09 +0200
From:	Tomasz Figa <tomasz.figa@...il.com>
To:	"Chaiken, Alison" <Alison_Chaiken@...tor.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Wolfram Sang <w.sang@...gutronix.de>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ian.campbell@...rix.com>,
	Pawel Moll <pawel.moll@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Olof Johansson <olof@...om.net>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: The future of DT binding maintainership

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/