From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLfpj-0005Xx-HS for qemu-devel@nongnu.org; Wed, 02 Nov 2011 14:46:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLfpi-0006Gu-6M for qemu-devel@nongnu.org; Wed, 02 Nov 2011 14:46:43 -0400 Received: from david.siemens.de ([192.35.17.14]:15050) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLfph-0006Gc-T3 for qemu-devel@nongnu.org; Wed, 02 Nov 2011 14:46:42 -0400 Message-ID: <4EB18FFF.7010603@siemens.com> Date: Wed, 02 Nov 2011 19:46:23 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4639B135-B96A-43A0-B4FA-6DDCBE3FBA92@suse.de> <4EB18172.1020905@adacore.com> <4EB18952.4080403@siemens.com> <4EB18C13.2030704@codemonkey.ws> <4EB18D1C.4090000@suse.de> In-Reply-To: <4EB18D1C.4090000@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] GSoC mentor summit QEMU users session List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , Fabien Chouteau , "qemu-devel@nongnu.org Developers" On 2011-11-02 19:34, Alexander Graf wrote: > Anthony Liguori wrote: >> On 11/02/2011 01:17 PM, Jan Kiszka wrote: >>> On 2011-11-02 18:44, Fabien Chouteau wrote: >>>> On 31/10/2011 14:12, Peter Maydell wrote: >>>>> On 29 October 2011 14:52, Alexander Graf wrote: >>>>>> A lot of people seem to also have code that doesn't make sense >>>>>> upstream, for example implementing a one-off device that only >>>>>> really matters for their own devboard which nobody else owns. >>>>>> For such cases, having a plugin framework would be handy. I >>>>>> interestingly enough got into the same discussion on LinuxCon >>>>>> with some QEMU downstreams. >>>>> >>>>> If we get the qdev rework done then I think we're probably in >>>>> a better position to have a plugin framework for devices. (There >>>>> are some issues about API and ABI stability guarantees, of course.) >>>>> >>>> >>>> Interesting, we have a "plug-in" implementation in our Qemu branch. It >>> >>> We have a "plugin" model here as well. It's really simple: the plugin is >>> loaded dynamically into the QEMU process and can access any global >>> function and variable. Of course, this breaks regularly. >> >> Yes, this is the Right Model. >> >> All of the work is in making the interfaces not break regularly. >> Loading a shared object is easy enough. > > I agree. In fact, we could even do it the same way as the kernel and > build all our internal hw pieces as shared objects. > > Then users who want to cut down QEMU can just remove .so files instead > of messing with the build system or code. We should also be able to establish an EXPORT_SYMBOL concept, ie. only export those functions that are supposed to be part of a component API. Will be some work initially, but should be off long term, both to QEMU in maintaining stable APIs and to external components in using the proper ones. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux