On Tue, May 21, 2019 at 06:23:49PM -0600, Simon Glass wrote: > 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? It's evidently not necessary to use the data: current dtbs don't have type information and the kernel clients work. This is true both in flat tree and actual OF implementations. Properties are bytestrings, and the consumer parses them itself based on the binding. > 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? The base model is a free tree of nodes, each node with a set of name/value pairs (properties), the values all being bytestrings. Bindings then add additional intepretation on top of that. > Is adding type > information enough to be considered a semantic change? Definitely. > I feel that > existing tools already infer it. They have two ways of doing so: 1) heuristics or 2) using the binding for all the relevant nodes and properties to interpret the properties. (1) is unreliable, (2) is reliable but needs a *lot* of extra information to correct interpret the data > > 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
Attachment:
signature.asc
Description: PGP signature
