[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-discuss] Device model from a dynamically loaded shared library
From: |
Peter Maydell |
Subject: |
Re: [Qemu-discuss] Device model from a dynamically loaded shared library |
Date: |
Tue, 5 Feb 2019 12:36:23 +0000 |
On Tue, 5 Feb 2019 at 03:27, <address@hidden> wrote:
>
> The company I work for uses QEMU as a simulated target for our
> operating system products. Several of our customers would like to
> integrate proprietary device models into QEMU, but so far are not
> willing to integrate the models directly into QEMU sources. I think
> this is largely a fear of the amount of time it will take to learn the
> QEMU sources.
>
> What they are instead asking for is a simple "device add" capability
> where they can load a shared library with their code and hook physical
> address read and write operations into calls to the simulated devices.
Hi -- this idea does come up from time to time, but it isn't really
something we would want to do as a project, I'm afraid.
There are a couple of related points here:
* firstly, whether the API is exposed as a shared library
interface or just as function calls you can make when you
build a C file into QEMU proper doesn't affect how easy
or difficult it is to use -- it's the same functions either way
* QEMU's internal APIs are not stable (in a similar way to
the Linux kernel's internal APIs being subject to change),
and we don't really want to commit to a stable API here in
the way that a DLL interface would require
* a facility that makes it easy for people to write device models
and use them with QEMU without contributing them upstream is
a facility that imposes a significant maintenance/support
burden on us as an upstream project, but provides us with
no compensating benefits (we don't get new device models because
all our users are keeping them to themselves), so it's not
very attractive from our point of view
* this sort of DLL interface can be seen as an attempt to do
an end-run around the GPL licensing requirements for code
like device models that is integrated with QEMU, so sees
pushback from that point of view too
I think there is an out-of-tree patchset to add SystemC support
to QEMU -- you might find that worth investigating.
thanks
-- PMM