Re: [RFC] devicetree: new FDT format version

On Wed, Jan 24, 2018 at 09:47:47AM -0600, Rob Herring wrote:

On Tue, Jan 23, 2018 at 3:17 PM, Frank Rowand [off-list ref] wrote:

quoted

On 01/23/18 04:42, David Gibson wrote:

quoted

On Mon, Jan 22, 2018 at 03:01:52PM -0600, Rob Herring wrote:

quoted

On Mon, Jan 22, 2018 at 2:09 AM, Frank Rowand [off-list ref] wrote:

quoted

Hi All,

I've tried to create a decent distribution list, but I'm sure I've missed
someone or some important list.  Please share this with anyone you think
will be affected.

I have been playing around with some thoughts for some additions to
the devicetree FDT aka blob format.

I would like to get the affected parties thinking about how additions to
the format could improve whichever pieces of FDT related technology you
work on or care about.  In my opinion, the FDT format should change
very infrequently because of the impact on so many projects that have
to work together to create a final solution, plus the many many users
of those projects.

A few things discussed before:
- Adding type information Even just tagging phandles would be good.

I'm a bit dubious about this.  It would have to be "hints" only -
there's not really anyway we can put in authoritative type
information, since dtc itself doesn't really know that.  It's also
hard to see how that could be done in a way which wouldn't either a)
require very awkward parallel lookup of the data and type information
or b) not be backwards compatible (even read only).

I never said it was possible. :) I'm just trying to enumerate possible
FDT format changes because I don't think we want to continuously
trickle out FDT changes even if they are backwards compatible.

quoted

quoted

quoted

- Allow applying overlays by just appending to the blob. The need for
this is somewhat gone now that libfdt can just fully apply overlays.

I'm not really sure what you want here.  I mean you could easily allow
the format to allow multiple appended overlays, and define that to
mean the overlaid result.  At some point *something* is going to have
to really do the application, so I'm not sure that it really buys you
that much.  It also makes nearly every operation on the tree in libfdt
horrible to implement, at least within the other constraints the
interface was designed around; you'll continually have to scan the
entire tree just in case some other overlay fragment has some bearing
on the thing you're looking at.  It confuses the interface too: what
does "node offset" mean if the same node could be built up from
overlay fragments at multiple offsets.

The idea was to avoid applying overlays to flattened trees at all.

That's fine if you're basically just passing the flattened tree(s)
through to the next stage.  You can also potentially make changes to
the tree by adding an additional overlay on the end.  But if you want
to read *anything* from a flattened tree in this format, it's
appallingly difficult:

Say you want to do an fdt_getprop() - just about the most basic thing
you can.  You look through the base tree and it's not there.  But you
can't return NOTFOUND yet, because it might be added in an overlay.
Now you have to go through every overlay, and each fragment in each
overlay.  You have to resolve each fragment's target path.  You have
to compare that target path to the one of your current node (which
itself needs an expensive fdt_get_path() to retrieve).  Do some fiddly
string jiggery pokery to work out the right relative path, and finally
scan the overlay node for the property.

None of this can be cached, because libfdt doesn't allocate, and
doesn't have any notion of context or state in which things could be
stored anyway.

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