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@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxx> > > > > 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:
signature.asc
Description: PGP signature
