From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L8fr1-0005UI-1r for qemu-devel@nongnu.org; Fri, 05 Dec 2008 13:56:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L8fqw-0005Sn-JU for qemu-devel@nongnu.org; Fri, 05 Dec 2008 13:56:42 -0500 Received: from [199.232.76.173] (port=40394 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L8fqw-0005Sk-Bd for qemu-devel@nongnu.org; Fri, 05 Dec 2008 13:56:38 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]:59471) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L8fqv-0002p8-Np for qemu-devel@nongnu.org; Fri, 05 Dec 2008 13:56:38 -0500 Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate01.web.de (Postfix) with ESMTP id B548AFA4A6EF for ; Fri, 5 Dec 2008 19:56:33 +0100 (CET) Received: from [88.64.13.18] (helo=[192.168.1.198]) by smtp08.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1L8fqr-0003bI-00 for qemu-devel@nongnu.org; Fri, 05 Dec 2008 19:56:33 +0100 Message-ID: <49397957.4090602@web.de> Date: Fri, 05 Dec 2008 19:56:23 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <3056442136ca43729c6a2aec02c038aa.squirrel@www.boonen.name> <49393B8D.40209@codemonkey.ws> <493970B9.3060807@redhat.com> In-Reply-To: <493970B9.3060807@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig523A3EDF04620D58AE4BC5D7" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: Modular qemu? 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig523A3EDF04620D58AE4BC5D7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > Anthony Liguori wrote: >> Plugins are not the solution though. >=20 > What about non-plugin dlopen()? Right now building qemu (with all > options enabled) requires a large amount of libraries, hence a lot of > dependencies. For example, a server setup that will only be used with > -vnc needs to have SDL installed. This will only get worse with opengl= > support. >=20 > I'm thinking of something similar to linux kernel modules: no backward > compatible ABI, simply load-on-demand functionality that can be package= d > separately to reduce dependencies. With kvm integrated, we could even > make the cpu emulator an optional loadable module. At work, we are currently using this model to separate a very special machine emulation from the latest and greatest qemu (or kvm-userspace) core. We only patch the core with support to load "machine libraries" that provide additional QEMUMachine definitions. The idea is definitely _not_ to distribute a binary-only machine library with the product one day, but to ease the build process. We also face the unavoidable API breakages from time to time, and the whole things is not really clean due to callbacks into the core all over the place, but otherwise it does its job. As it is not clean and we are still busy with more important stuff, I haven't posted any RFC yet. The biggest issue, besides finding a consensus if such pluging concepts are desired at all, is working out clean (but not necessarily stable) APIs for calling from the plugins into the core. Right now we simply export everything. Jan --------------enig523A3EDF04620D58AE4BC5D7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkk5eVsACgkQniDOoMHTA+kCxACfeGnPDNRQrPlQJlQ6vgfnqnWb FvUAnRkTExxmJw/KCMgxl1vH48J+6rAr =okiJ -----END PGP SIGNATURE----- --------------enig523A3EDF04620D58AE4BC5D7--