On Tue, 5 Feb 2019 at 03:27, <[email protected]> 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
