| Message ID | 20201019075224.14803-1-kraxel@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ui: build spice and opengl as module. | expand |
Hi On Mon, Oct 19, 2020 at 12:06 PM Gerd Hoffmann <kraxel@redhat.com> wrote: > - Add QemuSpiceOps, reorganize spice stubs. > - Add support for module dependencies. > - Build spice-core modular, and make the existing spice > modules (audio, chardev, qxl) depend on spice-core. > - Build egl-headless display and opengl helpers modular > (pretty easy thanks to module dependencies). > > Gerd Hoffmann (14): > spice: add module helpers > spice: add QemuSpiceOps, move migrate_info > spice: move qemu_spice_init() to QemuSpiceOps. > spice: move display_init() to QemuSpiceOps. > spice: move add_interface() to QemuSpiceOps. > spice: move auth functions to QemuSpiceOps. > spice: move display_add_client() to QemuSpiceOps. > spice: wire up monitor in QemuSpiceOps. > spice: load module when enabled on the cmdline > modules: dependencies infrastructure > modules: add spice dependencies > spice: flip modules switch > opengl: build egl-headless display modular > opengl: build opengl helper code modular > Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> thanks! > include/ui/qemu-spice-module.h | 44 ++++++++++++++++++ > include/ui/qemu-spice.h | 42 +---------------- > audio/spiceaudio.c | 4 +- > chardev/spice.c | 2 +- > monitor/misc.c | 2 +- > monitor/qmp-cmds.c | 6 +-- > softmmu/vl.c | 10 ++-- > ui/spice-core.c | 31 +++++++++---- > ui/spice-input.c | 6 +-- > ui/spice-module.c | 85 ++++++++++++++++++++++++++++++++++ > util/module.c | 44 ++++++++++++++++-- > ui/meson.build | 28 +++++++++-- > 12 files changed, 232 insertions(+), 72 deletions(-) > create mode 100644 include/ui/qemu-spice-module.h > create mode 100644 ui/spice-module.c > > -- > 2.27.0 > > > >
On Mon, 2020-10-19 at 09:52 +0200, Gerd Hoffmann wrote: > - Add QemuSpiceOps, reorganize spice stubs. > - Add support for module dependencies. > - Build spice-core modular, and make the existing spice > modules (audio, chardev, qxl) depend on spice-core. > - Build egl-headless display and opengl helpers modular > (pretty easy thanks to module dependencies). > Hi Gerd, others, I am happy to see the work you are doing with modularizing qemu, but I think there also needs to be corresponding work with libvirt's ability to properly detect qemu functionality in light of this modularization. Right now the QMP interface for probing "spice support" is quite a big hammer, and doesn't allow for any nuance. As I've looked into other aspects of how libvirt detects qemu functionality, it seems there is a lot of room for improvement in how qemu advertises it's functionality - which goes well beyond the issues of modularization. If you have any pointers to and discussion or plans in this regard, I'd appreciate it. Otherwise I'll look into doing something in this space myself. Thanks, Bruce
On Mon, Oct 26, 2020 at 10:27:54AM -0600, Bruce Rogers wrote: > On Mon, 2020-10-19 at 09:52 +0200, Gerd Hoffmann wrote: > > - Add QemuSpiceOps, reorganize spice stubs. > > - Add support for module dependencies. > > - Build spice-core modular, and make the existing spice > > modules (audio, chardev, qxl) depend on spice-core. > > - Build egl-headless display and opengl helpers modular > > (pretty easy thanks to module dependencies). > > Hi Gerd, others, Cc'ing John Snow who looks at qmp/qapi too right now. > I am happy to see the work you are doing with modularizing > qemu, but I think there also needs to be corresponding work > with libvirt's ability to properly detect qemu functionality > in light of this modularization. I've tried to not change qemu behavior, but there are limits to this as modularization brings some new constellations. > Right now the QMP interface for probing "spice support" is > quite a big hammer, and doesn't allow for any nuance. Yep. Specifically the CONFIG_SPICE=y and spice modules not installed at runtime is problematic I think. > As I've looked into other aspects of how libvirt detects qemu > functionality, it seems there is a lot of room for improvement in how > qemu advertises it's functionality - which goes well beyond the issues > of modularization. Well, everything which involves qom objects should work just fine, even with modules. You can see objects supported by qemu via qapi introspection, and that should work just fine with objects being implemented in modules. > If you have any pointers to and discussion or plans in this regard, I'd > appreciate it. Otherwise I'll look into doing something in this space > myself. For -audiodev and -display we could turn stuff into objects (simliar to -chardev) and just use the object class registry instead of having a private registry. That would make things also visible in qom introspection. The spice problem has been discussed in the past, but IIRC we didn't end up with a plan. We could have spice register a dummy qom object (say 'feature-spice'). Not sure this is a good idea though. take care, Gerd