Re: integrating dtc into the sim/ tree

[Mike Frysinger <vapier at gentoo dot org>]

On Wed 20 Aug 2014 18:06:35 Joel Brobecker wrote:
> > moxie is the only one that hard requires dtc (it might be limited to
> > maintainer mode).  but the larger point is to delete a large body of
> > custom code that the sim has today for parsing its device tree like
> > data format and convert over to the standard format that the rest of
> > the world is using now.  and longer term, make it so we can share dtc
> > files between linux/u-boot/qemu such that you can feed a fdt to the
> > sim and it'll automatically bring up hardware in the same way as the
> > kernel would have found it.
> > 
> > atm, you have to basically write two different device trees with
> > different syntax and names, then feed one to the sim and the other to
> > the kernel.  and hope they don't get out of sync :).
> > 
> > there's basically no chance of people rewriting the existing sim code
> > so that it gains all the same functionality as the public dtc, and
> > then keeping it in sync.  i'd rather just gut it and be done, and get
> > the dtc updates for free.
> 
> My 2 cents: This sounds interesting, but on the other hand, I have
> this feeling that requiring dtc might be a big ask. I'm not sure
> how portable the dtc project is, and how easy it is to get it
> installed. I went to the "Device Tree Compiler" page you referenced,
> and it doesn't give at all the impression of being a mature and
> widespread project... For instance, I was looking for the documentation
> in order to check for things like installation, OS support,
> requirements, etc. I ended up looking inside the source tree itself,
> and found Documentation/manual.txt and README, but none of them answered
> any of these questions. I am also wondering about releases and such,
> but couldn't really find much about it.

it's pretty mature imo.  lemme phrase it this way: it's a hard requirement 
nowadays for ARM on Linux, so it's def viable.  i think a lot of the docs 
you're referring to is because the library aims to be used literally 
everywhere -- vendor BIOS, vendor kernels, etc...  the license readme explains 
this a bit more:
https://git.kernel.org/cgit/utils/dtc/dtc.git/tree/README.license

> I hope this explains why I would personally feel a little more
> comfortable if that dependency remained optional.
> 
> Now, if the project was really super easy to install and completely
> portable (think Linux & Windows, of course, but also Darwin,
> Solaris...), I would consider making it mandatory.

i'd be willing to make sure it builds everywhere.  the external dependencies 
in libfdt are extremely light (by design -- it wants to work in your typical 
BIOS).  basically it needs str/mem funcs and not ancient stdint.h.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.