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: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-11 15:53 KVM call minutes for Jan 11 Chris Wright
2011-01-11 15:53 ` [Qemu-devel] " 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.