On Wed, Nov 14, 2018 at 04:29:23PM -0800, Simon Glass wrote: > Hi David, > > We had a discussion today about a possible new v18 DT format[1] > > You have seen Frank Rowand's design from January[2]. Frank presented > material at the conference[3] and I wrote up something up too [4]. Yes, I didn't like the original proposal very much - overly complicated, but the revised one I suggested back looks reasonably do-able. Your proposal seems to have a rather different focus from Frank's - his is mostly about cleaner handling of overlays and similar extensions. Yours is mostly about size. Can I ask what's the concern here? I mean, first of all, I'm finding it a bit hard to believe that a few kiB of device tree really mean much in the context of a vaguely modern system. But more specifically is the concern in-memory size? Or size on persistent storage, disk or flash? Those two would be amenable to different approaches to mitigate. > Obviously this is a big undertaking and there is no guarantee it will > go anywhere, nor that everyone will agree. So, looking at your document, really the only approach that seems likely to be worth the trouble from the numbers you present is (B). Although for (B), I'm not quite sure how you're encoding things not to disallow cases that we do actually want to support. (J) seems like it might be an interesting approach, coupled with a variant of (B), although the numbers you give aren't too promising. (F) & (G) involve changing not just the dt encoding, but its content. That means changes to the clients and is therefore a vastly bigger undertaking than just changing the encoding format. > But one thing that became apparent is that it is likely that a few > parts of the libfdt API might become tricky to support. For example, > those that return a struct fdt_property are exposing the internals of > the DTB format. Hm, yes, exposing struct fdt_property that way does limit our options, although it has some nice properties elswhere in the interface, which is why it was included in the first place. > Grant Likely suggested dealing with the API problems first so we can > signal the potential changes. So I am thinking of taking a look at > this and sending a few patches. > > What do you think? Well, I guess I'll look at the patches and see. > > Regards, > Simon > > [1] https://etherpad.openstack.org/p/Device_Tree > [2] https://www.spinics.net/lists/devicetree-spec/msg00608.html > [3] https://linuxplumbersconf.org/event/2/contributions/168/ > [4] https://goo.gl/jRRv1S > -- 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
