From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1L8fsA-0005xl-0V
	for qemu-devel@nongnu.org; Fri, 05 Dec 2008 13:57:54 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1L8fs7-0005xP-LX
	for qemu-devel@nongnu.org; Fri, 05 Dec 2008 13:57:52 -0500
Received: from [199.232.76.173] (port=40434 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1L8fs7-0005xM-DN
	for qemu-devel@nongnu.org; Fri, 05 Dec 2008 13:57:51 -0500
Received: from yx-out-1718.google.com ([74.125.44.156]:23230)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1L8fs7-0002zN-57
	for qemu-devel@nongnu.org; Fri, 05 Dec 2008 13:57:51 -0500
Received: by yx-out-1718.google.com with SMTP id 3so98846yxi.82
	for <qemu-devel@nongnu.org>; Fri, 05 Dec 2008 10:57:50 -0800 (PST)
Message-ID: <493979AB.3070308@codemonkey.ws>
Date: Fri, 05 Dec 2008 12:57:47 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Modular qemu?
References: <3056442136ca43729c6a2aec02c038aa.squirrel@www.boonen.name>	<49393B8D.40209@codemonkey.ws>
	<493970B9.3060807@redhat.com>
In-Reply-To: <493970B9.3060807@redhat.com>
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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Avi Kivity wrote:
> Anthony Liguori wrote:
>> Plugins are not the solution though.
>
> 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.

Practically speaking, how helpful is this?  You still need to have the 
libraries present at build time and it's arguable about how much text 
savings you get because there's some cruft added from loading the 
libraries themselves.

If we had cleaner, self-registering interfaces, doing the dlopen() is 
real easy.  I definitely think we should move to that model.  The 
dlopen() part is somewhat orthogonal.

Regards,

Anthony Liguori

> I'm thinking of something similar to linux kernel modules: no backward 
> compatible ABI, simply load-on-demand functionality that can be 
> packaged separately to reduce dependencies.  With kvm integrated, we 
> could even make the cpu emulator an optional loadable module.