qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 00/14] ui: build spice and opengl as module.


From: Gerd Hoffmann
Subject: Re: [PATCH 00/14] ui: build spice and opengl as module.
Date: Tue, 27 Oct 2020 06:58:24 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]