From: Paul Sokolovsky <pmiscml@gmail.com>
To: Paul Borman <paul.borman@windriver.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] QEmu as a Device Software Optimization tool
Date: Sat, 28 Jul 2007 18:55:58 +0300 [thread overview]
Message-ID: <582026785.20070728185558@gmail.com> (raw)
In-Reply-To: <E7EEEFEC-94F0-4B71-B988-3F142FEA69DE@windriver.com>
Hello Paul,
Friday, July 27, 2007, 12:25:13 PM, you wrote:
> The embedded space contains a vast number of boards, often only
> different by what devices are use, where they are located, etc.
> Building a new version of qemu for each board would be burdensome.
> The hope would be that we could build a generic qemu (for an
> architecture family), say, ppc_generic, which then read an external
> file (which, in our case, will be generated from board description)
> and configure itself according to that. Further, by allowing devices
> to be loaded vi dlopen(), devices can be added after qemu has been
> built. This would also allow the developer to specify the exact
> location of the device, rather than having a list of IRQ's and base
> ports, etc.
> For the embedded world, yes, "outsiders" are certainly going to want
> to define new platforms and more than likely, provide their own
> custom devices. They key is they do not need to muck with the real
> internals of qemu, just the part that picks the bits and pieces to use.
Funnily, this is the same argumentation as I used more than
half-year ago when there was last big discussion on the need of
flexible and generalized config file:
http://lists.gnu.org/archive/html/qemu-devel/2006-10/msg00249.html
Then, it received rather cool response, I actually don't remember any
single vote for flexible/structural config and plugins. Well, I always
thought that just a small time will be required for more wider
audience to chime in and come back to this idea ;-).
> Oh, and if I am an outsider, then absolutely the answer is yes!, I
> already have had the need :-)
> -Paul
[]
--
Best regards,
Paul mailto:pmiscml@gmail.com
next prev parent reply other threads:[~2007-07-28 15:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-26 19:48 [Qemu-devel] QEmu as a Device Software Optimization tool n schembr
2007-07-27 9:25 ` Paul Borman
2007-07-28 15:55 ` Paul Sokolovsky [this message]
2007-07-27 14:24 ` [Qemu-devel] " Brian Johnson
-- strict thread matches above, loose matches on Subject: below --
2007-07-20 14:58 [Qemu-devel] Patch for OHW bootinfos Tero Kaarlela
2007-07-26 16:34 ` [Qemu-devel] QEmu as a Device Software Optimization tool Paul Borman
2007-07-26 16:58 ` Thiemo Seufer
2007-07-26 17:33 ` Even Rouault
2007-07-26 19:00 ` andrzej zaborowski
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=582026785.20070728185558@gmail.com \
--to=pmiscml@gmail.com \
--cc=paul.borman@windriver.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.