qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 --]

             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).