From: "Einar Larsson" <larsson.einar@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Unified device model
Date: Sun, 23 Apr 2006 23:03:51 +0200 [thread overview]
Message-ID: <449a8f9a0604231403w6987bd93v83b56d99819d8255@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]
I think that a device model with support for devices in shared libraries
combined with dynamic definition of the simulated HW would be great to be
able to support a large number of HW variants in QEmu.
I have developed several full system simulators for large embedded systems,
and we have always ended up with a systems with a very small component
runtime combined with a script based description of the system to simulate.
All parts of the system except the component loading and instantiation was
implemented as dynamically loaded components. I have worked on
implementations that use a pure C based component model as well as systems
that supports both C and C++ bindings for interface implementation.
I have not been able to find any information about the proposed Bochs
component model. Stanislav: where can I find any information about the Bochs
plugin architecture that you talk about?
Among the open source component frameworks i guess that XPCOM used in the
Mozilla products is one of the most interesting. It currently support C++,
Python and Java bindings but it can easily support C as well.
/Einar
I strongly support the idea of being able to use shared objects to be
> able to have a more dynamic device model; I can work on moving some of
> the drivers over to whatever new model that you figure out.
>
> It'd be nice too to have a dynamic board definition. For instance,
> being able to describe in a configuration file a board with some odd
> configuration (eg. 10 serial port, no IDE controller) without
> recompiling would be helpful. I'm not sure what kind of file format's
> appropriate.
>
> The number of supported devices on QEMU is going to explode... Having a
> good scalable architecture is going to be very useful.
>
> - Alex
>
>
[-- Attachment #2: Type: text/html, Size: 1989 bytes --]
next reply other threads:[~2006-04-23 21:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-23 21:03 Einar Larsson [this message]
[not found] <1b33de610604170003q43b6c453ub94d77b1a10ed43b@mail.gmail.com>
2006-04-17 7:09 ` [Qemu-devel] Unified device model pete sullivan
-- strict thread matches above, loose matches on Subject: below --
2006-04-08 19:57 Stanislav Shwartsman
2006-04-08 19:12 ` Jim C. Brown
2006-04-08 19:17 ` Johannes Schindelin
2006-04-08 19:27 ` Leonardo E. Reiter
2006-04-09 6:29 ` Stanislav Shwartsman
2006-04-08 19:28 ` Jim C. Brown
2006-04-09 6:26 ` Stanislav Shwartsman
2006-04-09 10:38 ` Paul Brook
2006-04-09 14:55 ` Jim C. Brown
2006-04-09 15:21 ` Paul Brook
2006-04-09 15:28 ` Sam Barnett-Cormack
2006-04-09 16:08 ` Jim C. Brown
2006-04-09 19:56 ` Stanislav Shwartsman
2006-04-09 21:02 ` Fabrice Bellard
2006-04-09 15:10 ` Jim C. Brown
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=449a8f9a0604231403w6987bd93v83b56d99819d8255@mail.gmail.com \
--to=larsson.einar@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).