From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BivZe-0005xm-4h for qemu-devel@nongnu.org; Fri, 09 Jul 2004 09:37:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BivZc-0005xZ-66 for qemu-devel@nongnu.org; Fri, 09 Jul 2004 09:37:57 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BivZc-0005xW-2f for qemu-devel@nongnu.org; Fri, 09 Jul 2004 09:37:56 -0400 Received: from [81.209.184.159] (helo=dd2718.kasserver.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BivX9-00078E-4v for qemu-devel@nongnu.org; Fri, 09 Jul 2004 09:35:23 -0400 Received: from [192.168.0.7] (dsl-082-082-147-030.arcor-ip.net [82.82.147.30]) by dd2718.kasserver.com (Postfix) with ESMTP id CB62AAEE06 for ; Fri, 9 Jul 2004 15:35:18 +0200 (CEST) Message-ID: <40EE9F13.405@fabianowski.de> Date: Fri, 09 Jul 2004 15:35:15 +0200 From: Bartosz Fabianowski MIME-Version: 1.0 Subject: Re: [Qemu-devel] plugins References: <40ED8EF0.1040501@bellard.org> <40EF1357.1000600@witch.dyndns.org> <40EFD7E2.7000607@witch.dyndns.org> In-Reply-To: <40EFD7E2.7000607@witch.dyndns.org> Content-Type: text/plain; charset=us-ascii; 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 > With a plugin system (all it takes is 2 files: an text/XML file which > contains the info on this plugin, and a .so file which is the plugin Binary plugins, especially closed source ones, always create the problem of binary compatibility. QEMU's 0.5 version number already indicates that although it works very well already, it is nowhere near finished. Features change very quickly in CVS, just think about how pci was an experimental option a short while back and now it's the default. I think it would be really hard to come up with an API that would remain stable for multiple releases at this point. Also, the need to maintain backwards compatibility would hamper QEMU's development. And finally, creating and maintaining an API would drain lots of resources from QEMU development while benefiting only very few people who want to distribute closed source plugins. Maybe at a much later stage, when QEMU is stable and mature, binary plugins will make sense. But for now, it seems like the source code extensibility QEMU offers is good enough. - Bartosz