From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FXlkM-0006j5-1H for qemu-devel@nongnu.org; Sun, 23 Apr 2006 17:03:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FXlkL-0006ir-Ie for qemu-devel@nongnu.org; Sun, 23 Apr 2006 17:03:57 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FXlkL-0006in-Bw for qemu-devel@nongnu.org; Sun, 23 Apr 2006 17:03:57 -0400 Received: from [64.233.184.237] (helo=wproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FXlmQ-0003Am-GA for qemu-devel@nongnu.org; Sun, 23 Apr 2006 17:06:06 -0400 Received: by wproxy.gmail.com with SMTP id 36so921801wra for ; Sun, 23 Apr 2006 14:03:56 -0700 (PDT) Message-ID: <449a8f9a0604231403w6987bd93v83b56d99819d8255@mail.gmail.com> Date: Sun, 23 Apr 2006 23:03:51 +0200 From: "Einar Larsson" Subject: Re: [Qemu-devel] Unified device model MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_29508_16111802.1145826231218" Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org ------=_Part_29508_16111802.1145826231218 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 Boch= s 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 > > ------=_Part_29508_16111802.1145826231218 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I think that a device model with support for devices in shared librari= es combined with dynamic definition of the simulated HW would be great to b= e able to support a large number of HW variants in QEmu.

I have dev= eloped several full system simulators for large embedded systems, and we ha= ve always ended up with a systems with a very small component runtime combi= ned 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 Boc= hs component model. Stanislav: where can I find any information about the B= ochs 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 binding= s but it can easily support C as well.

/Einar
 

I strongly support the idea of being able to use shar=
ed objects to be

able to have a more dynamic device model; I can work on moving some of<=
br>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 abl=
e to describe in a configuration file a board with some odd

configuration (eg. 10 serial port, no IDE controller) without
recomp=
iling would be helpful.  I'm not sure what kind of file format's
appropr=
iate.

The number of supported devices on QEMU is going to explode...=
 Having a

good scalable architecture is going to be very useful.

- Alex
------=_Part_29508_16111802.1145826231218--