From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FSbKa-0003Wh-3D for qemu-devel@nongnu.org; Sun, 09 Apr 2006 10:56:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FSbKY-0003Vm-3Q for qemu-devel@nongnu.org; Sun, 09 Apr 2006 10:55:59 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FSbKX-0003Vj-UN for qemu-devel@nongnu.org; Sun, 09 Apr 2006 10:55:57 -0400 Received: from [128.8.10.163] (helo=po1.wam.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FSbOy-0002OV-Qp for qemu-devel@nongnu.org; Sun, 09 Apr 2006 11:00:32 -0400 Received: from jbrown.mylinuxbox.org (jma-box.student.umd.edu [129.2.253.219]) by po1.wam.umd.edu (8.12.11.20060308/8.12.10) with ESMTP id k39EtuZI018441 for ; Sun, 9 Apr 2006 10:55:56 -0400 (EDT) Date: Sun, 9 Apr 2006 10:55:55 -0400 From: "Jim C. Brown" Subject: Re: [Qemu-devel] Unified device model Message-ID: <20060409145555.GA5081@jbrown.mylinuxbox.org> References: <200604091138.31242.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <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 On Sun, Apr 09, 2006 at 11:38:28AM +0100, Paul Brook wrote: > 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. > Same here. > 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. A binary plugin API and a source plugin API (one that requires each driver device to be recompiled for each of the platforms (Xen, qemu, bochs, etc.) would probably be equally hard to design and maintain. With a binary plugin API you at least win out. > I can't see > any good reasons why open source devices would need to be broken out into a > separate shared library. > I think the case was already made for this. Xen's hardware emulation, while based on qemu's, is already ahead in several aspects. A separate library would make it more convenient for these changes to be shared back with qemu. Or with E/OS. This is actually a completely separate issue from a unified device driver API (as qemu could support the API, but only in source code form, or could require that drivers be linked in statically, etc) and should be recognized as such. > 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. Considering that the ABI does not guarantee compatibility between versions, I am inclined to agree. No reason the drivers themselves can't be done in C++, but the API itself should be pure C. > > Paul > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.