From: Mike Frysinger <vapier@gentoo.org>
To: gdb@sourceware.org
Cc: Joel Brobecker <brobecker@adacore.com>,
Joel Sherrill <joel.sherrill@oarcorp.com>,
Anthony Green <green@moxielogic.com>
Subject: Re: integrating dtc into the sim/ tree
Date: Wed, 20 Aug 2014 15:30:00 -0000 [thread overview]
Message-ID: <1850909.FvmpfGFofc@vapier> (raw)
In-Reply-To: <20140820095347.GH4828@adacore.com>
[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]
On Wed 20 Aug 2014 11:53:47 Joel Brobecker wrote:
> > so after talking to myself, i guess the issue isn't so much with using
> > the system copy of dtc as it is with making it a hard requirement
> > (which is different from how the other packages use 3rd party libs --
> > they're all optional). might be able to reduce the requirement so
> > only the hw layers hard depend on it, but i'm not sure if even that is
> > possible.
>
> OK. Is that dependency on dtc something new? Or was it there already
> for certain sims and not others?
>
> Dependency requirements like these should be discussed on a
> case-per-case basis, I think. And the answers to the questions
> you ask above (can it be made optional, what functionality gets
> lost, etc) definitely influence the decision.
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.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-08-20 15:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-18 22:14 gdb moxie build failure Joel Sherrill
2014-08-19 5:38 ` integrating dtc into the sim/ tree Mike Frysinger
2014-08-19 6:26 ` Joel Brobecker
2014-08-20 9:33 ` Mike Frysinger
2014-08-20 9:53 ` Joel Brobecker
2014-08-20 15:30 ` Mike Frysinger [this message]
2014-08-20 16:06 ` Joel Brobecker
2014-08-20 16:11 ` Joel Sherrill
2014-08-20 16:19 ` Joel Brobecker
2014-08-20 16:37 ` Joel Sherrill
2014-08-21 1:31 ` Mike Frysinger
2014-08-21 1:25 ` Mike Frysinger
2014-08-21 7:32 ` Joel Brobecker
2014-08-21 9:05 ` Pedro Alves
2014-08-21 13:58 ` Joel Sherrill
2014-08-21 16:25 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1850909.FvmpfGFofc@vapier \
--to=vapier@gentoo.org \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.org \
--cc=green@moxielogic.com \
--cc=joel.sherrill@oarcorp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox