Hi David, On Mon, 20 May 2019 at 23:20, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, May 20, 2019 at 03:18:08PM -0600, Simon Glass wrote: > > Hi David, > > > > On Sat, 24 Nov 2018 at 02:52, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > 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. > > > > Did that move ahead? I have been a little submerged for a while. > > If it has, I haven't heard about it. OK thanks. > > > > 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. > > > > What do you think about adding type information to the .dtb format? > > That is in the 'detailed design' section. > > By adding new tags we could add type information in a much less > intrusive manner than current proposals. That said, I'm pretty uneasy > about this. I'm concerned that if it's generally there, then > supposedly end-clients will start using it, fundamentally changing the > semantic model of the device tree[1]. DT type information should > really be something like ELF debug information - an aid to > intermediate tools, but not intended for use by the final consumer. Are you saying this because you feel that type information is not necessary to use the data? I can certainly imagine such an implementation and its an intriguing idea. > > [1] You can make a case for changing the semantic model, but if you > want that you should really change the whole thing from the ground > up, not try to graft it onto the OF-style DT model. Hmm. What exactly is the semantic model of DT? Is adding type information enough to be considered a semantic change? I feel that existing tools already infer it. Regards, Simon > > -- > 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
