From: Adam Litke <agl@us.ibm.com>
To: Alon Levy <alevy@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: spice vdagent protocol, was Re: [Qemu-devel] KVM call minutes for Jan 11
Date: Thu, 13 Jan 2011 09:01:34 -0600 [thread overview]
Message-ID: <1294930894.2197.78.camel@aglitke> (raw)
In-Reply-To: <20110111183301.GO4581@playa.tlv.redhat.com>
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
next prev parent reply other threads:[~2011-01-13 15:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-11 15:53 [Qemu-devel] KVM call minutes for Jan 11 Chris Wright
2011-01-11 18:33 ` spice vdagent protocol, was " Alon Levy
2011-01-13 15:01 ` Adam Litke [this message]
2011-01-13 19:18 ` Alon Levy
2011-01-13 19:44 ` Adam Litke
2011-01-13 20:11 ` Alon Levy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1294930894.2197.78.camel@aglitke \
--to=agl@us.ibm.com \
--cc=alevy@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).