From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L8gUo-0003u9-Bx for qemu-devel@nongnu.org; Fri, 05 Dec 2008 14:37:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L8gUm-0003tQ-HK for qemu-devel@nongnu.org; Fri, 05 Dec 2008 14:37:49 -0500 Received: from [199.232.76.173] (port=60865 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L8gUm-0003tM-BS for qemu-devel@nongnu.org; Fri, 05 Dec 2008 14:37:48 -0500 Received: from mx2.redhat.com ([66.187.237.31]:50238) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L8gUl-0008Ud-Nb for qemu-devel@nongnu.org; Fri, 05 Dec 2008 14:37:48 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mB5Jbkws016284 for ; Fri, 5 Dec 2008 14:37:46 -0500 Message-ID: <49398314.4070909@redhat.com> Date: Fri, 05 Dec 2008 21:37:56 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Modular qemu? References: <3056442136ca43729c6a2aec02c038aa.squirrel@www.boonen.name> <49393B8D.40209@codemonkey.ws> <493970B9.3060807@redhat.com> <20081205185420.GA26481@networkno.de> <49397AC6.9070201@redhat.com> <493980B7.1010808@codemonkey.ws> In-Reply-To: <493980B7.1010808@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Anthony Liguori wrote: > Avi Kivity wrote: >> >> You build qemu once, but with separate sub-packages: >> >> qemu >> qemu-sdl >> qemu-vnc >> qemu-tcg >> qemu-kvm > > Fair enough, but we're getting the cart before the horse. We need to > have clean internal separations between these components before a > shared library interface really matters. Note, this is really just > dividing QEMU into shared libraries, it's not really a plugin mechanism. Right, I even introduced it as such. I don't think the separation will be difficult (not does it need to be perfect, given that we're not committing to an ABI). > > I'm less interested in the shared library bits (although I understand > it's usefulness from a distro perspective) and more interested in > being able to build out a lot of these things. Parse failure. What does building out mean? ./configure --disable-blah? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.