From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Bivmk-0000Nb-6t for qemu-devel@nongnu.org; Fri, 09 Jul 2004 09:51:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Bivmj-0000NP-Nl for qemu-devel@nongnu.org; Fri, 09 Jul 2004 09:51:29 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bivmj-0000NM-KH for qemu-devel@nongnu.org; Fri, 09 Jul 2004 09:51:29 -0400 Received: from [213.146.130.142] (helo=trantor.org.uk) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Bivjz-0000Jr-4V for qemu-devel@nongnu.org; Fri, 09 Jul 2004 09:48:39 -0400 Subject: Re: [Qemu-devel] plugins From: Gianni Tedesco In-Reply-To: <40EE9F13.405@fabianowski.de> References: <40ED8EF0.1040501@bellard.org> <40EF1357.1000600@witch.dyndns.org> <40EFD7E2.7000607@witch.dyndns.org> <40EE9F13.405@fabianowski.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-yKEGt647tpW0U3HD0sBd" Date: Fri, 09 Jul 2004 14:48:48 +0100 Message-Id: <1089380928.3101.21.camel@sherbert> Mime-Version: 1.0 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 --=-yKEGt647tpW0U3HD0sBd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-07-09 at 15:35 +0200, Bartosz Fabianowski wrote: > > With a plugin system (all it takes is 2 files: an text/XML file which=20 > > contains the info on this plugin, and a .so file which is the plugin >=20 > Binary plugins, especially closed source ones, always create the problem=20 > of binary compatibility. QEMU's 0.5 version number already indicates=20 > that although it works very well already, it is nowhere near finished.=20 > Features change very quickly in CVS, just think about how pci was an=20 > experimental option a short while back and now it's the default. Adding PCI could easily have been binary backwards compatible. Anyway, we're not talking about necissarily having a stable or backwards compatible ABI, just an API which makes developing new code simpler and makes each module more flexible. It doesn't have to be there to encourage out-of-tree development at all. > I think=20 > it would be really hard to come up with an API that would remain stable=20 > for multiple releases at this point. Also, the need to maintain=20 > backwards compatibility would hamper QEMU's development. And finally,=20 > creating and maintaining an API would drain lots of resources from QEMU=20 > development while benefiting only very few people who want to distribute=20 > closed source plugins. No developing and maintaining a stable or backwards compatible ABI would do that. An API that doesn't have to be stable or backwards compatible won't. > Maybe at a much later stage, when QEMU is stable=20 > and mature, binary plugins will make sense. But for now, it seems like=20 > the source code extensibility QEMU offers is good enough. No, I think plugins should be built from the main qemu source and external developers would ideally release new plugins as source distributions to compile against your qemu core. Anything else requires maintaining an ABI. Another benefit of DSO based plugins is saving memory and virtual address space, only loading the plugins which are required. It would also save on disk space as common code can be shared amongst the various qemu targets. --=20 // Gianni Tedesco (gianni at scaramanga dot co dot uk) lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import 8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D --=-yKEGt647tpW0U3HD0sBd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA7qJAkbV2aYZGvn0RAuLDAJ0YmWOG4suB+rgkU8SCNzACcUuZcQCfYiyy W5v17knFkn92YtlY4rAgh+Y= =71yZ -----END PGP SIGNATURE----- --=-yKEGt647tpW0U3HD0sBd--