On Saturday 26 of October 2013 10:11:06 David Gibson wrote: > On Fri, Oct 25, 2013 at 10:21:22AM -0500, Jon Loeliger wrote: > > > On 10/25/2013 12:43 AM, Grant Likely wrote: > > > > On Thu, 24 Oct 2013 22:51:28 +0100, Stephen Warren > > > > <swarren@xxxxxxxxxxxxx>> > > > > wrote: > > > >> From: Stephen Warren <swarren@xxxxxxxxxx> > > > >> > > > >> This is a very quick proof-of-concept re: how a DT schema checker > > > >> might > > > >> look if written in C, and integrated into dtc. > > > > > > > > Thanks for looking at this. > > > > > > > > Very interesting. Certainly an expedient way to start checking > > > > schemas, > > > > and for certain bindings it may be the best approach. The downside > > > > is it forces a recompilation of DTC to bring in new bindings and > > > > it isn't a great meduim for mixing schema with documentation in > > > > the bindings.> > > > > This approach would certainly require recompiling something. I threw > > > the code into dtc simply because it was the easiest container for > > > the demonstration. It could be a separate DT validation utility if > > > we wanted, although we'd need to split the DT parser from dtc into > > > a library to avoid code duplication. The resultant utility could be > > > part of the repo containing the DTs, so it didn't end up as a > > > separate package to manage. > > > > > > I think the additional documentation could be added as comments in > > > the > > > validation functions, just like IIRC it was to be represented as > > > comments even in the .dts-based schema proposals. > > > > DTers, > > > > I think the additional benefit of starting with a direct C > > implementation is that it causes us to begin to actually > > codify the schema requirements. Sure, it may not be ideal > > at first, but over time it may reveal consistent patterns > > that can be extracted. And it may reveal what a real schema > > might look like and how it might be expressed better. Which > > is to say that perhaps we are letting "perfect" get in the > > way of "good enough to start"? > > > > In the meantime, someone has shown us the code and we can > > get started. It's a Small Matter of Refactoring later. :-) > > Yes! This! > > Think of this prototype as a mechanism for collating and applying a > bunch of schemas to the tree. At the moment the schemas are all hard > coded in C, but it can be extended to load some or all of them > dynamically from a description / template / whatever. > > That also gives us the flexibility to start out with a simple but > limited schema language which handles common cases, while leaving the > complex cases in C, at least until we understand the requirements well > enough to extend the schema language. This is fine as an intermediate step, but I'm afraid that the overhead of work needed to describe all the bindings using C language directly will be pretty big. C language isn't really best fitted for such purposes. If we agree to base on this, but solely as a mechanism and a base for further work, my idea would be to introduce a schema description language anyway and then some code generator that would generate C code from schemas described using such language (and possibly also something to generate textual documentation from schemas, so we could have a central repository of indexed DT bindings, for example on [1] - maybe kerneldoc could be reused here). Such design would allow for describing a lot of cases using a simple description language, while leaving the possibility of adding inline C snippets, like PHP in HTML, to handle those super complex ones. [1] https://www.kernel.org/doc/htmldocs/ Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
