[RFC 00/15] Device Tree schemas and validation

[Chaiken, Alison]

Rob Herring in devicetree/msg06598.html
> This is interesting approach using the dts syntax,

Benoit Cousson in devicetree/msg06617.html
> it has the big advantage of re-using the parser already included in DTC for
> free. In term or readability, it avoids to re-defining a brand new syntax for
> people who are already familiar with the DTS one.

Stephen Warren wrote in devicetree/msg06676.html:
> DT is a language for representing data.
> The validation checks described by schemas are rules, or code, and not static
> data.

The syntax of the existing device-tree source is strikingly similar to that of
the widely used JavaScript Object Notation, better known as JSON.  JSON has many
parsers, validators and schemata already in existence.  Assuredly as many coders
know how to program JSON as know C.

JSON makes some sense for representation of device-trees, because, as the
authoritative json.org explains, "JSON is a text format that is completely
language independent but uses conventions that are familiar to programmers of
the C-family of languages . . . JSON is a natural representation of data for the
C family of programming languages."

Benoit Cousson remarks in devicetree/msg06617.html:
> The bindings definition being quite open, there is no easy way to
> ensure proper schema / bindings without careful review of the
> schema.

Stephen Warren continues in devicetree/msg06676.html:
> Overall, I believe perhaps the single most important aspect of any DT
> schema is schema inheritance or instancing,

David Gibson comments in devicetree/msg06725.html:
> define the notion of dt "patterns" or "templates".  A dt
> pattern is to a dt node or subtree as a regex is to a string - it
> provides a reasonably expressive way of defining a family of dt
> nodes.  These would be defined in an extension / superset of dt
> syntax.

I violently agree with Stephen and David and believe that inheritance
offers a partial solution to the problem Benoit describes.  What about
improving compliance by explicitly making use of inheritance with
device-tree include files?  Suppose we consider supplementing the ARM
tree's skeleton.dtsi tree-root with board.dtsi, cpu.dtsi,
daughtercard.dtsi . . .  Suppose then we require board-level dts files
to include board.dtsi, and furthermore that the CPU node for the board
to be described in a DTSI file that must itself include cpu.dtsi.
Then the dtc itself could in effect check perform some constraint
checking.  Device vendors could offer <arch>.dtsi and <particular
chip>.dtsi that users of those products would be required to include.

A related question: what DTS files will a validator compare against a schema?
Assuredly given the existing ability of nodes and properties in a
hierarchy of include files to override and modify one another, the
post C-preprocessed and compiled single-file is the one wanted, that
is, the output from

	       $CC $CPP_FLAGS -o foo.tmp foo.dts
	       dtc -O dts -i arch/arm/boot/dts foo.tmp

Some other suggestions:

   Let's not make the documentation derived from schemata and DTS files
tree-structured.    Otherwise we end up with GNU info, ahem.

   Stephen Warren previously contributed a useful bindings checklist.  We should
try to roll that checklist into any validator.

Benoit promises in  devicetree/msg06617.html:
> Being the very first one, you might get a free beer... meaning there
> might be such thing as a free beer :-)

I'm presenting a talk about device-tree for Embedded Linux Conference
Europe, http://sched.co/17ozhPE, and hope that some of you come flame
me in person there.  If so, I will actually buy you a free beer, but
not until after the second seminar I must give that afternoon!

-- 
Alison Chaiken
Mentor Embedded Software Division
Fremont, CA
GMT-8