Re: Linux Plumbers v18 DT-format followup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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



[Index of Archives]     [Device Tree]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux