Re: [RFC PATCH 1/2] Preserve datatype information when parsing dts

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

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

On Tue, Dec 12, 2017 at 12:48:10PM +0000, Grant Likely wrote:
> On Tue, Dec 12, 2017 at 6:14 AM, David Gibson
> <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> > On Tue, Nov 28, 2017 at 11:57:09AM +0000, Grant Likely wrote:
> >> The current code throws away all the data type and grouping information
> >> when parsing the DTS source file, which makes it difficult to
> >> reconstruct the data format when emitting a format that can express data
> >> types (ie. dts and yaml). Use the marker list to mark the beginning and
> >> end of each integer array block (<> and []), the datatype contained in
> >> each (8, 16, 32 & 64 bit widths), and the start of each string.
> >>
> >> At the same time, factor out the heuristic code used to guess a property
> >> type at emit time. It is a pretty well defined standalone block that
> >> could be used elsewhere, for instance, when emitting YAML source. Factor
> >> it out into a separate function so that it can be reused, and also to
> >> simplify the write_propval() function.
> >>
> >> When emitting, group integer output back into the same groups as the
> >> original source and use the REF_PATH and REF_PHANDLE markers to emit the
> >> the node reference instead of a raw path or phandle.
> >>
> >> Signed-off-by: Grant Likely <grant.likely-5wv7dgnIgG8@public.gmane.org>
> >
> > I'm a bit dubious how well forcing the marker mechanism to do all this
> > stuff it was never intended for can work in the long term.  Still,
> > it's an interesting experiment.
> 
> As long as the actual data is stored as flat buffer, the markers
> mechanism works quite well for this. I tried doing something entirely
> separate, and it turned out to be awful. Another alternative is to
> break up the flat buffer into a chain of data blocks with attached
> type information, but that is a very invasive change.
> 
> This approach has the advantage of being robust on accepting both
> typed and anonymous data. If the markers are not there then the
> existing behaviour can be maintained, but otherwise it can emit a
> higher fidelity of source language.

Hm, true.  The approach is growing on me.  I guess what I'm still
dubious about is how much this type annotation can get us to approach
the YAML model.  For example, YAML can distinguish between [ [1, 2],
[3, 4] ] and [1, 2, 3, 4] which isn't really feasible in dtc.

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