Date:	Tue, 30 Jul 2013 11:44:53 +1000
From:	David Gibson <david@...son.dropbear.id.au>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	"jonsmirl@...il.com" <jonsmirl@...il.com>,
	Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"ksummit-2013-discuss@...ts.linuxfoundation.org" 
	<ksummit-2013-discuss@...ts.linuxfoundation.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Ian Campbell <ian.campbell@...rix.com>,
	Pawel Moll <Pawel.Moll@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Richard Cochran <richardcochran@...il.com>,
	Tomasz Figa <tomasz.figa@...il.com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Domenico Andreoli <cavokz@...il.com>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Dave P Martin <Dave.Martin@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]

On Sat, Jul 27, 2013 at 10:11:16PM -0700, James Bottomley wrote:
> On Sat, 2013-07-27 at 21:28 -0600, Grant Likely wrote:
> > On Sat, Jul 27, 2013 at 2:25 PM, Grant Likely <grant.likely@...retlab.ca> wrote:
> > > On Sat, Jul 27, 2013 at 2:01 PM, jonsmirl@...il.com <jonsmirl@...il.com> wrote:
> > >> On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely <grant.likely@...retlab.ca> wrote:
> > >>> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel <arend@...adcom.com> wrote:
> > >>>> 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.
> > >>>
> > >>> Draft an example and show us how it would look!  :-)  There is
> > >>> absolutely nothing preventing us from expressing a DT in XML format,
> > >>> or even using XSLT to define DT schema while still using our current
> > >>> .dts syntax. It would be trivial to do lossless translation between
> > >>> .dts syntax and xml.
> > >>>
> > >>> The problem that I have with XML and XSLT is that it is very verbose
> > >>> and not entirely friendly to mere-mortals. However, I'm more than
> > >>> willing to be proved wrong on this point.
> > >>
> > >> I considered this approach a while ago and discarded it. It would work
> > >> but it is just too much of a Frankenstein monster.
> > >>
> > >> Much cleaner to modify dtc to take a schema as part of the compilation
> > >> process. The schema language itself has no requirement to look like
> > >> DTS syntax. Whoever wrote dtc probably has a favorite language that
> > >> would be good for writing schemas in.
> > >
> > > Making it part of dtc is a required feature as far as I'm concerned.
> > > Using XML/XSLT and dtc-integration are not mutually exclusive, but I
> > > digress.
> > 
> > Oops, ignore the XSLT bit. XSLT isn't schema and has no bearing on the
> > discussion of schema. Sorry for the noise.
> 
> XSLT is a transform language ... you'd use it say to transform xml to
> dtc, so it would be an integral component of an xml/xslt based schema.
> 
> If you want actually to describe and have validated the xml schema
> itself, then you'd use xsd (XML schema description language) and its
> associated tools.
> 
> I'm not saying you *should* do this, just that it's possible (plus I've
> just blown my kernel cred by knowing about xml, sigh).

Heh.  So, it was said in jest, but that actually raises an important
point.

There are basically two criteria to keep in mind for our
representation of schemas:
   1) Adequate expressiveness to validate a sufficiently large part,
of a sufficiently large number of bindings to be useful.
   2) Ease of use and ease of learning **for the target audience**.

To the best of my knowledge xsd would do well on (1), but I'm not
convinced it does very well on (2).  In an environment where XML was
already widely used, XSD would make perfect sense.  Here, I think it
would be pretty ugly to wire onto the existing DT tools and
infrastructure, and unpleasantly unfamiliar for many kernel and board
developers trying to work with DT schemas.


So, by way of investigation, let me propose an alternative expression
of schemas, that I'm also not convinced we should do, but is possible
and expressive.  It's illustrative, because it's kind of the polar
opposite approach to XSD: just use C.

dtc already has a (so far limited) "checks" mechanism which verifies
various aspects of DT content.  These are implemented by C functions
in checks.c.  There's obviously ample expressiveness - you can express
any constraint you want that way.  It can be pretty verbose, and
fiddly.  A good library of helper functions can mitigate that, but
it's not clear how much.  On the other hand, a very good fraction of
people working with this will already be familiar with C, which is a
big plus.  This is, after all, the reason that the dts syntax is
chiefly C inspired.

Now, in practice, I think we will want a more convenient schema
language (just as we wanted dts, rather than manually constructing
FDTs as C structures).  But I absolutely do think, that the schema
handling should be handled as plugins to the checks mechanism -
basically we'd have a validate_schemas() check function.

I also think we should consider the option of having a simple and
straightforward schema language which handles, say, 80% of cases with
a fall back to C for the 20% of curly cases.  That might actually be
simpler to work with in practice than a schema language which can
express absolutely anything, at the cost of being awkward for simple
cases or difficult to get your head around.

Remember, a schema language is only a win if it is - for the target
audience - more convenient to express schemas in than C.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists