Re: [Qemu-devel] QOM-ify QemuConsoles ...

[Anthony Liguori <anthony@codemonkey.ws>]

Andreas Färber <afaerber@suse.de> writes:

> Hi Gerd,
>
> Am 20.03.2013 10:55, schrieb Gerd Hoffmann:
>> I think the next logical step ahead is to QOM-ify the QemuConsoles, so
>> we can link the QemuConsole to the thing actually backing it.  For a
>> graphical console that would be the emlated graphic device.  For a text
>> console it would be the serial line or monitor hooked up to it.
>> 
>> With this in place we should be able to answer questions like "which
>> device backs this QemuConsole" by inspecting the object tree and handle
>> requests like "do a screendump of this device please".  It will also be
>> useful to setup input routing: "pointer events from $this QemuConsole
>> should to $that virtual input device".
>> 
>> Hints how to do that best?  Pointers to sample code to look at?  From a
>> brief look it seems we only QOM-ified emulated devices and not host-side
>> objects yet ...
>
> You could look at virtio-rng. TPM doesn't use QOM yet AFAIR.

I think the first step is to figure out what the relationships are.  I
was looking through the changes and vaguely, it appears that its:

 - Each UI has one or more DisplayChangeListeners

 - Each DisplayChangeListener can be mapped to 1 or more QemuConsoles

 - Each QemuConsole can then be mapped to some thing that's drawing.

So DisplayChangeListener is basically a QemuConsole multiplexer.  If we
are keeping this basic design, then I think it's just a matter of
converting DisplayChangeListener to a QOM object, QemuConsole to QOM
object, then finally each UI.

Then you can select via links what QemuConsoles map to each DCL.

Regards,

Anthony Liguori

>
> Cheers,
> Andreas
>
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg