Patchwork GSoC mentor summit QEMU users session

login
register
mail settings
Submitter Anthony Liguori
Date Nov. 2, 2011, 6:51 p.m.
Message ID <4EB1914C.8070706@codemonkey.ws>
Download mbox | patch
Permalink /patch/123314/
State New
Headers show

Comments

Anthony Liguori - Nov. 2, 2011, 6:51 p.m.
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<agraf@suse.de>   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
>
>
Stefan Hajnoczi - Nov. 3, 2011, 7:38 a.m.
On Wed, Nov 2, 2011 at 6:51 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> @@ -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();

We need taint marker support from day 1.  Or perhaps a nicer thing:
require each module to declare a support URL string.  QEMU will print
out support URLs when displaying version information or on startup.
This way it's easy to indentify who to ask for help if QEMU appears
broken - we'll know if a third-party plugin is involved.

Stefan

Patch

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;
  }