From patchwork Wed Nov 2 18:51:56 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Anthony Liguori X-Patchwork-Id: 123314 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [140.186.70.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id AB351B6F7C for ; Thu, 3 Nov 2011 05:52:12 +1100 (EST) Received: from localhost ([::1]:58372 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLfuz-0007tr-62 for incoming@patchwork.ozlabs.org; Wed, 02 Nov 2011 14:52:09 -0400 Received: from eggs.gnu.org ([140.186.70.92]:32869) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLfus-0007mA-71 for qemu-devel@nongnu.org; Wed, 02 Nov 2011 14:52:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLfuq-0007G5-DQ for qemu-devel@nongnu.org; Wed, 02 Nov 2011 14:52:02 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:38226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLfuq-0007Fu-6V for qemu-devel@nongnu.org; Wed, 02 Nov 2011 14:52:00 -0400 Received: by gya6 with SMTP id 6so507921gya.4 for ; Wed, 02 Nov 2011 11:51:59 -0700 (PDT) Received: by 10.150.237.5 with SMTP id k5mr6758071ybh.4.1320259919561; Wed, 02 Nov 2011 11:51:59 -0700 (PDT) Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com. [70.123.132.139]) by mx.google.com with ESMTPS id p5sm9597218anl.18.2011.11.02.11.51.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Nov 2011 11:51:58 -0700 (PDT) Message-ID: <4EB1914C.8070706@codemonkey.ws> Date: Wed, 02 Nov 2011 13:51:56 -0500 From: Anthony Liguori User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Alexander Graf 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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.160.173 Cc: Jan Kiszka , "qemu-devel@nongnu.org Developers" , Fabien Chouteau , Peter Maydell Subject: Re: [Qemu-devel] GSoC mentor summit QEMU users session X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On 11/02/2011 01:34 PM, 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. This is totally untested and won't probably build, but we can do something like this. We should also follow http://www.gnu.org/prep/standards/html_node/Dynamic-Plug_002dIn-Interfaces.html Regards, Anthony Liguori > > > Alex > > diff --git a/hw/qdev.c b/hw/qdev.c index 50976dd..1d5aea7 100644 --- a/hw/qdev.c +++ b/hw/qdev.c @@ -58,6 +58,7 @@ static DeviceInfo *qdev_find_info(BusInfo *bus_info, const cha { DeviceInfo *info; +again: /* first check device names */ for (info = device_info_list; info != NULL; info = info->next) { if (bus_info && info->bus_info != bus_info) @@ -77,6 +78,20 @@ static DeviceInfo *qdev_find_info(BusInfo *bus_info, const ch continue; return info; } + + /* try to load an appropriately named module */ + { + char *path = g_module_build_path(PREFIX, info->name); + GModule *mod = g_module_open(path, G_MODULE_BIND_LOCAL); + void (*init)(void); + + if (g_module_symbol(mod, "mod_init", &init)) { + init(); + goto again; + } + } + + return NULL; }