On Fri, 26 Aug 2022 at 08:51, Sebelev, Vladimir <vladimir.sebe...@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+06u01e16z...@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
