Re: [PATCH v3 4/5] dtc: Drop dts source restriction for yaml output

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2964 bytes --]

On Mon, Oct 11, 2021 at 08:22:54AM -0500, Rob Herring wrote:
> On Mon, Oct 11, 2021 at 2:19 AM David Gibson
> <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> >
> > On Tue, Jul 27, 2021 at 12:30:22PM -0600, Rob Herring wrote:
> > > YAML output was restricted to dts input as there are some dependencies
> > > on source annotations which get lost with other input formats. With the
> > > addition of markers by the checks, YAML output from dtb format becomes
> > > more useful.
> > >
> > > Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >
> > Urgh.  There's not really anything wrong with this patch of itself,
> > but it really underlines my feeling that the whole yaml output thing
> > is a bunch of hacks in pursuit of a bogus goal.
> 
> Validating DTs is a bogus goal?

Goal probably wasn't the right word.  Validating DTs is fine.  The
bogosity comes from doing the conversion to YAML essentially without
reference to the bindings / schemas.  Bindings describe how to
interpret the DT's bytestrings into meaninful numbers or whatever, so
using the bindings is the only reliable way of converting those
bytestrings into some more semantically useful representation.

> > Yaml output wants to include information that simply isn't present in
> > the flattened tree format (without considering bindings), so it relies
> > on formatting conventions in the dts, hence this test in the first
> > place.  This alleges it removes a restriction, but it only works if a
> > bunch of extra heuristics are able to guess the types correctly.
> 
> The goal here is to validate dtb files which I'd think you'd be in
> favor of given your above opinions. For that to work, we have to
> transform the data into the right types somewhere.

Yes - and that should be done with reference to specific bindings, not
using fragile heuristics.

> We don't need any
> heuristics for that. For the most part, it is done using the
> definitive type information from the schemas themselves to format the
> data.

Exactly.  That type information should come *from the schemas*.  Not
from separately maintained and fragile approximations to parts of the
schemas embedded into dtc.

> The exception is #*-cells patterns which need to parse the tree
> to construct the type information. Given dtc already has all that
> knowledge in checks, it's easier to do it there rather than
> reimplement the same parsing in python.

dtc only has parts of that knowledge in checks.  The checks have been
written with the assumption that in ambiguous cases we can just punt
and not run the check.  For the goal of truly parsing everything, the
current design of the checks subsystem really isn't adequate.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]