On Sun, Sep 16, 2018 at 02:08:10PM -0500, Rob Herring wrote:
> On Sat, Sep 15, 2018 at 12:08 PM Grant Likely <Grant.Likely@xxxxxxx> wrote:
> >
> >
> >
> > > On 14 Sep 2018, at 19:39, Rob Herring <robh@xxxxxxxxxx> wrote:
> > >
> > > Commit 32b9c6130762 ("Preserve datatype markers when emitting dts format")
> > > fails to split string lists into multiple strings and instead just outputs
> > > a "\0" between strings. This is broken when the input is dtb or fs tree.
> > >
> > > This could be fixed in the dts output where the problem was introduced,
> > > but fix it by adding markers on the input side instead. This will allow
> > > for any possible future uses of type markers.
> >
> > I’m not keen putting the resolution in the input stage. It creates a weird split between when the type predictions happen. Strings are predicted at input, and everything else at output. I would be happier if a middle processing stage were added to go over the entire tree and add missing data tokens. Then the output could drop all data prediction logic.
>
> The only other prediction is 4 byte multiple cells are uint32, so it's
> not like there's a whole bunch of prediction left.
>
> The middle stage would be in the checks infra which is where I'd
> envision using the markers more. But we have ways to order checks and
> there's already some phandle fixups IIRC, so that could work. I'll
> defer to David. I don't really care (other than I've already written
> this way.)
Like Grant, I think leaving all the detection to output is a better
idea. I think it's clearer how things work if TYPE_ markers (other
than TYPE_NONE) are only present when we really do have information on
what the types should be. Since we don't have reliable type
information, only heuristics, with -Ifs or -Idtb I think we shouldn't
have any type markers, and instead fallback to guesswork at the point
of output.
--
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
