On Wed, Jan 24, 2018 at 09:47:47AM -0600, Rob Herring wrote: > On Tue, Jan 23, 2018 at 3:17 PM, Frank Rowand <frowand.list@xxxxxxxxx> wrote: > > On 01/23/18 04:42, David Gibson wrote: > >> On Mon, Jan 22, 2018 at 03:01:52PM -0600, Rob Herring wrote: > >>> On Mon, Jan 22, 2018 at 2:09 AM, Frank Rowand <frowand.list@xxxxxxxxx> wrote: > >>>> 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. > > >>> - 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
Attachment:
signature.asc
Description: PGP signature
