qemu-devel
[Top][All Lists]
Advanced

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

Re: spice vdagent protocol, was Re: [Qemu-devel] KVM call minutes for Ja


From: Adam Litke
Subject: Re: spice vdagent protocol, was Re: [Qemu-devel] KVM call minutes for Jan 11
Date: Thu, 13 Jan 2011 09:01:34 -0600

On Tue, 2011-01-11 at 20:33 +0200, Alon Levy wrote:
> > Spice guest agent:
> > - virt agent, matahari, spice agent...what is in spice agent?
> > - spice char device
> >   - mouse, copy 'n paste, screen resolution change
> > - could be generic (at least input and copy/paste)
> >   - send protocol details of what is being sent
> > - need to look at how difficult it is to split it out from spice
> >   (how to split out in qemu vs. libspice)
> > - goal to converge on common framework
> > - more discussion on char device vs. protocol
> >   - eg. mouse_set breaks if mouse channel is part pv and part spice specific
> > - Alon will send link to protocol and try to propose new interfaces
> 
> http://spice-space.org/page/Whiteboard/AgentProtocol
> 
> That's the corrent documentation. Notably the clipboard is a todo there, I'll
> try to get that filled in. I'll continue this discussion on a separate thread 
> later.

Thanks for sending this out Alon.  The use cases you have outlined are
very similar to the ones we have for virtagent.  The main differences I
can see so far are the the data encoding strategy and the spice agent's
method for delivery of events (mouse, etc).

Virtagent implements an RPC interface and uses xmlrpc-c to encode data
in XML.  This approach seems more general-purpose, extensible and easier
to manage over the long term than relying on a custom binary
representation.

As for event delivery, virtagent does not yet have an interface to allow
external programs to subscribe to events.  I am sure this can be done in
a generic way that is backwards-compatible with the current spice
architecture.  Such an interface should allow arbitrary programs to
subscribe to events but have no dependencies on those programs.  I am
not sure if something like D-Bus would be appropriate for Linux guests.
We'd need to consider Windows too.  

I see no reason why the core qemu use cases (shutdown, exec, copyfile)
and the spice use cases (mouse, copy-paste, graphics reconfiguration)
cannot (and should not) be satisfied by a single agent.  Going forward,
I think we'd need to agree on the wire protocol and guest-side event
subscription.

Thoughts?

-- 
Thanks,
Adam




reply via email to

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