From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLft6-00075s-0E for qemu-devel@nongnu.org; Wed, 02 Nov 2011 14:50:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLft4-00070o-Dz for qemu-devel@nongnu.org; Wed, 02 Nov 2011 14:50:11 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:64325) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLft4-00070T-6M for qemu-devel@nongnu.org; Wed, 02 Nov 2011 14:50:10 -0400 Received: by gya6 with SMTP id 6so506109gya.4 for ; Wed, 02 Nov 2011 11:50:06 -0700 (PDT) Message-ID: <4EB190DA.1010506@codemonkey.ws> Date: Wed, 02 Nov 2011 13:50:02 -0500 From: Anthony Liguori 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> <4EB18FFF.7010603@siemens.com> In-Reply-To: <4EB18FFF.7010603@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Jan Kiszka Cc: Peter Maydell , Alexander Graf , Fabien Chouteau , "qemu-devel@nongnu.org Developers" On 11/02/2011 01:46 PM, Jan Kiszka wrote: > 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. Not at first. We don't need yet another interface that we have to try to maintain. Until things stabilize internally, the module interface should be completely unstable. Regards, Anthony Liguori > > Jan >