From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FSXJZ-0001r7-QT for qemu-devel@nongnu.org; Sun, 09 Apr 2006 06:38:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FSXJX-0001qu-RQ for qemu-devel@nongnu.org; Sun, 09 Apr 2006 06:38:41 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FSXJX-0001qr-LW for qemu-devel@nongnu.org; Sun, 09 Apr 2006 06:38:39 -0400 Received: from [65.74.133.6] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FSXNv-00030w-LM for qemu-devel@nongnu.org; Sun, 09 Apr 2006 06:43:12 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Unified device model Date: Sun, 9 Apr 2006 11:38:28 +0100 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604091138.31242.paul@codesourcery.com> 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 > >>I am wondering about making unified device models architecture for open > >>source simulators. > >>The device models will be used in QEMU, Bochs, Xen and other open source > >>simulators which would use the device models. > > > >I would support this idea, if it was possible. > > Why not ? > You always could consider to add simple modules C++ to QEMU or build C++ > device -> C device interface bridge ... I think to be acceptable to qemu (and probably also for Xen) the devices would have to be written in C. C++ is more pain that it's worth in this context. Of course there's no reason why we couldn't use the subset of C that's also valid C++. You could also write C++ wrappers round the interface for bochs to use. I'm not a fan of binary plugins (for the same reasons I'm don't like binary kernel modules), and don't think there's any real need to them. I can't see any good reasons why open source devices would need to be broken out into a separate shared library. If you do want to accommodate proprietary binary plugins then C++ is a really bad idea. The C++/libstdc++ ABI simply isn't stable enough to make this a realistic option. Paul