From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FSbjf-0006Bs-Gb for qemu-devel@nongnu.org; Sun, 09 Apr 2006 11:21:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FSbjd-0006Bf-0n for qemu-devel@nongnu.org; Sun, 09 Apr 2006 11:21:54 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FSbjc-0006Bc-SN for qemu-devel@nongnu.org; Sun, 09 Apr 2006 11:21:52 -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 1FSbo3-0001uD-Vl for qemu-devel@nongnu.org; Sun, 09 Apr 2006 11:26:28 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Unified device model Date: Sun, 9 Apr 2006 16:21:42 +0100 References: <200604091138.31242.paul@codesourcery.com> <20060409145555.GA5081@jbrown.mylinuxbox.org> In-Reply-To: <20060409145555.GA5081@jbrown.mylinuxbox.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604091621.45594.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'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. You've missed my point. The only reason I can see for wanting binary plugins is so that people can distribute proprietary closed-source device emulation. A stable source API is a prerequisite for any sort of binary plugins. > > 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. I don't buy that. We either share the same drivers (in which case keeping the two in sync is trivial) or we don't. All of the systems under consideration are [L]GPL licences. We can easily copy the source, so I don't think being able to copy bits of binary goo gains us anything. I don't think executable size is a valid argument either. Device emulation code generally isn't that big so the overhead of breaking it up into multiple shared libraries would outweigh the benefits of not loading the bits you're not using. Paul