[Top][All Lists]
[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