Re: [PATCH v3] Loading new machines and devices from external modules

[Peter Maydell]

On Fri, 26 Aug 2022 at 08:51, Sebelev, Vladimir
<vladimir.sebelev@auriga.com> wrote:
> Anton previously sent explanation of our position. Nobody
> commented. Could you please comment on it? It's necessary for
> us to better understand your position.

The discussion was on this thread:
https://lore.kernel.org/qemu-devel/Yta+06u01e16zKTd@redhat.com/
Dan's email is a pretty straightforward summary of what
upstream's position is, and why we have that view.

I understand that the way QEMU is today is not helpful for you,
but it is the way it is. QEMU is not and doesn't really
seek to be a standardized simulator platform with a fixed
API that people can build device models for and then
stitch those device models together into platforms, and
have that work across different QEMU versions; and
wishing that it was doesn't make it so. The gap between
here and there is not just a 300 line patch, it is:

 * a significantly different/enlarged set of contributors
   (in the sense of "companies willing to invest money to work
   on the project and have it fulfil their requirements")
 * a major shift in project focus (for instance, it would
   have to care a lot more about providing well documented
   stable APIs to devices; it might need to care less about
   emulation performance improvements if they required
   breaking changes to existing devices)
 * a lot of work and restructuring to be able to provide
   that "we are a simulator platform with a clean interface
   that makes it easy to write and wire up device models"
   interface. A lot of work would be needed to clean up and
   separate out what are currently ad-hoc and legacy
   interfaces between different pieces of the codebase.
   We'd want to consider whether we wanted to provide
   SystemC interfaces and compatibility. Etc.

Perhaps it would be cool if that open source project existed;
but QEMU isn't currently it. The path to maybe causing QEMU
to get closer to that idea is not "throw a short patch onto
the mailing list", but to try to build a community of people
who (a) agree with you (b) are willing to contribute to the
upstream project to do the heavy lifting in the third
bullet point above (c) can make the case over time for
"these changes are good not just for us but also for you;
we're going to be around for the long term to help maintain
them; and we do our share of the work on the common parts
of the system that everybody benefits from".

QEMU has had big changes in focus before -- most notably
the addition of support for KVM and similar virtualization
interfaces to what was originally purely an emulator.
So it's not impossible -- but it isn't easy.

(Part 'c' is helpful for pretty much every non-trivial contribution
to any open source project, incidentally. But the more you're
trying to propose a major change in project focus the more
it matters.)

> From our point of view technical ban of external modules
> loading doesn't solve any of mentioned problems, but makes
> VP developer life harder.

Anything we provide as a user-facing interface is something
we have to support. Not providing "load machine from
external .so file" solves the problem of "this is not
something we want to support or think we are able to support".

For example, this patch doesn't solve the kind of problem you
list yourself in the commit message here:

> For example we’re now working on Raspberry Pi 4b implementation for our
> internal needs and we’re planning to merge it upstream. It’s based on some
> QEMU fork author of which wasn’t able to complete it and commit upstream.
> And it can’t be used with later QEMU without some efforts to port it
> to newer QEMU version.

Having that in an external .so that's loaded via an -add_machines
command line does nothing to make it work with multiple QEMU
versions: it will still only work with the QEMU version it
was based on, because newer ones will provide different
APIs and will have removed old functions that the code in
the .so is relying on. So providing a "-add_machines" option
is just going to cause a lot of bug reports of the form "my .so
doesn't work" where the answer is "you need to use the exact
matching QEMU version that the .so was built for". At which point
you might as well just have built the machine model into the
QEMU binary.

thanks
-- PMM