[Spice-devel,spice-protocol] Change usbredir messages to spicevmc messages

Submitted by Hans de Goede on Aug. 25, 2011, 5:19 p.m.

Details

Message ID 1314267576-11679-1-git-send-email-hdegoede@redhat.com
State New, archived
Headers show

Not browsing as part of any series.

Commit Message

Hans de Goede Aug. 25, 2011, 5:19 p.m.
While discussing various things with Alon in Vancouver, it came up that
having a channel which simply passes through data coming out of a qemu
chardev frontend unmodified, like the usbredir channel does, can be used
for a lot of other cases too. To facilitate this the usbredir channel code
will be turned into a generic spicevmc channel, which is just a passthrough
to the client, from the spicevmc chardev.

This patch renames the msg types to make clear that they are not usbredir
specific, but instead are generic spicevmc data passthrough messages. The
usbredir channel id is unmodified by this, although the same code and
messages can now be used for multiple purposes, we still need unique ids
for each purpose, so that the client knows how to interpret / represent the
passed through data.

Some examples of why having a generic spicevmc pass through is good:
1) We could add a monitor channel, allowing access to the qemu monitor from
the spice client, since the monitor is a chardev frontend we could re-use
the generic spicevmc channel server code, so all that is needed to add this
(server side) would be reserving a new channel id for this.

2) We could allow users to come up with new channels of their own, without
requiring qemu or server modification. The idea is to allow doing something
like this on the qemu startup cmdline:
-chardev spicevmc,name=generic,channelid=128

To ensure these new "generic" channels cannot conflict with newly added
official types, the must start at the SPICE_CHANNEL_USER_DEFINED_START value
this patch adds (128 or higher).

These new user defined channels could then either be used with a special
modified client, with client plugins (if we add support for those), or
by exporting them on the client side for use by an external ap, see below.

3) We could also add support to the client to make user-defined channels
end in a unix socket / pipe, allowing handling of the data by an external app,
we could for example have a new spice client cmdline argument like this:
--custom-channel unixsocket=/tmp/mysocket,channelid=128

This would allow for something like:
$random app on guest -> virtio-serial -> spicevmc chardev ->
 -> spicevmc channel -> unix socket -> $random app on client

4) On hind sight this could also have been used for the smartcard stuff,
with a 1 channel / reader model, rather then the current multiplexing code
where we've our own multiplexing protocol wrapper over the libcacard
smartcard protocol.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 spice/enums.h |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

Patch hide | download patch | download mbox

diff --git a/spice/enums.h b/spice/enums.h
index ffaba5c..8d68b36 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -331,7 +331,9 @@  enum {
     SPICE_CHANNEL_SMARTCARD,
     SPICE_CHANNEL_USBREDIR,
 
-    SPICE_END_CHANNEL
+    SPICE_END_CHANNEL,
+
+    SPICE_CHANNEL_USER_DEFINED_START = 128
 };
 
 enum {
@@ -521,15 +523,15 @@  enum {
 };
 
 enum {
-    SPICE_MSG_USBREDIR_DATA = 101,
+    SPICE_MSG_SPICEVMC_DATA = 101,
 
-    SPICE_MSG_END_USBREDIR
+    SPICE_MSG_END_SPICEVMC
 };
 
 enum {
-    SPICE_MSGC_USBREDIR_DATA = 101,
+    SPICE_MSGC_SPICEVMC_DATA = 101,
 
-    SPICE_MSGC_END_USBREDIR
+    SPICE_MSGC_END_SPICEVMC
 };
 
 #endif /* _H_SPICE_ENUMS */

Comments

On Thu, Aug 25, 2011 at 12:19:36PM +0200, Hans de Goede wrote:

ACK.

> While discussing various things with Alon in Vancouver, it came up that
> having a channel which simply passes through data coming out of a qemu
> chardev frontend unmodified, like the usbredir channel does, can be used
> for a lot of other cases too. To facilitate this the usbredir channel code
> will be turned into a generic spicevmc channel, which is just a passthrough
> to the client, from the spicevmc chardev.
> 
> This patch renames the msg types to make clear that they are not usbredir
> specific, but instead are generic spicevmc data passthrough messages. The
> usbredir channel id is unmodified by this, although the same code and
> messages can now be used for multiple purposes, we still need unique ids
> for each purpose, so that the client knows how to interpret / represent the
> passed through data.
> 
> Some examples of why having a generic spicevmc pass through is good:
> 1) We could add a monitor channel, allowing access to the qemu monitor from
> the spice client, since the monitor is a chardev frontend we could re-use
> the generic spicevmc channel server code, so all that is needed to add this
> (server side) would be reserving a new channel id for this.
> 
> 2) We could allow users to come up with new channels of their own, without
> requiring qemu or server modification. The idea is to allow doing something
> like this on the qemu startup cmdline:
> -chardev spicevmc,name=generic,channelid=128
> 
> To ensure these new "generic" channels cannot conflict with newly added
> official types, the must start at the SPICE_CHANNEL_USER_DEFINED_START value
> this patch adds (128 or higher).
> 
> These new user defined channels could then either be used with a special
> modified client, with client plugins (if we add support for those), or
> by exporting them on the client side for use by an external ap, see below.
> 
> 3) We could also add support to the client to make user-defined channels
> end in a unix socket / pipe, allowing handling of the data by an external app,
> we could for example have a new spice client cmdline argument like this:
> --custom-channel unixsocket=/tmp/mysocket,channelid=128
> 
> This would allow for something like:
> $random app on guest -> virtio-serial -> spicevmc chardev ->
>  -> spicevmc channel -> unix socket -> $random app on client
> 
> 4) On hind sight this could also have been used for the smartcard stuff,
> with a 1 channel / reader model, rather then the current multiplexing code
> where we've our own multiplexing protocol wrapper over the libcacard
> smartcard protocol.
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  spice/enums.h |   12 +++++++-----
>  1 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/spice/enums.h b/spice/enums.h
> index ffaba5c..8d68b36 100644
> --- a/spice/enums.h
> +++ b/spice/enums.h
> @@ -331,7 +331,9 @@ enum {
>      SPICE_CHANNEL_SMARTCARD,
>      SPICE_CHANNEL_USBREDIR,
>  
> -    SPICE_END_CHANNEL
> +    SPICE_END_CHANNEL,
> +
> +    SPICE_CHANNEL_USER_DEFINED_START = 128
>  };
>  
>  enum {
> @@ -521,15 +523,15 @@ enum {
>  };
>  
>  enum {
> -    SPICE_MSG_USBREDIR_DATA = 101,
> +    SPICE_MSG_SPICEVMC_DATA = 101,
>  
> -    SPICE_MSG_END_USBREDIR
> +    SPICE_MSG_END_SPICEVMC
>  };
>  
>  enum {
> -    SPICE_MSGC_USBREDIR_DATA = 101,
> +    SPICE_MSGC_SPICEVMC_DATA = 101,
>  
> -    SPICE_MSGC_END_USBREDIR
> +    SPICE_MSGC_END_SPICEVMC
>  };
>  
>  #endif /* _H_SPICE_ENUMS */
> -- 
> 1.7.5.1
> 
> _______________________________________________
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
Hi,

> Some examples of why having a generic spicevmc pass through is good:

(5) Redirect the serial or virtio console over spice.  Especially with
     spice-gtk it should be easy to wind up the spice client side to a
     vte widget.

cheers,
   Gerd
Hi,

On 08/25/2011 01:35 PM, Gerd Hoffmann wrote:
> Hi,
>
>> Some examples of why having a generic spicevmc pass through is good:
>
> (5) Redirect the serial or virtio console over spice. Especially with
> spice-gtk it should be easy to wind up the spice client side to a
> vte widget.

Right, so this would be very similar to doing the qemu
monitor over a spice channel. So what we need is some spice-gtk
code to plug a spicevmc channel into a vte widget, and then
we can add both a monitor and a serial-console channel :)

Regards,

Hans
On Thu, Aug 25, 2011 at 01:57:21PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/25/2011 01:35 PM, Gerd Hoffmann wrote:
> >Hi,
> >
> >>Some examples of why having a generic spicevmc pass through is good:
> >
> >(5) Redirect the serial or virtio console over spice. Especially with
> >spice-gtk it should be easy to wind up the spice client side to a
> >vte widget.
> 
> Right, so this would be very similar to doing the qemu
> monitor over a spice channel. So what we need is some spice-gtk
> code to plug a spicevmc channel into a vte widget, and then
> we can add both a monitor and a serial-console channel :)
> 

With the current code you would have to let both sides know what the new channels are:

qemu -chardev spicevmc,name=generic,channelid=128,id=mon -mon chardev=mon
# and same for virtio

spicy --spicevmc channelid=128,handler=vte
# just an example

> Regards,
> 
> Hans
> _______________________________________________
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
Hi,

On 08/26/2011 10:07 AM, Alon Levy wrote:
> On Thu, Aug 25, 2011 at 01:57:21PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 08/25/2011 01:35 PM, Gerd Hoffmann wrote:
>>> Hi,
>>>
>>>> Some examples of why having a generic spicevmc pass through is good:
>>>
>>> (5) Redirect the serial or virtio console over spice. Especially with
>>> spice-gtk it should be easy to wind up the spice client side to a
>>> vte widget.
>>
>> Right, so this would be very similar to doing the qemu
>> monitor over a spice channel. So what we need is some spice-gtk
>> code to plug a spicevmc channel into a vte widget, and then
>> we can add both a monitor and a serial-console channel :)
>>
>
> With the current code you would have to let both sides know what the new channels are:
>
> qemu -chardev spicevmc,name=generic,channelid=128,id=mon -mon chardev=mon
> # and same for virtio
>
> spicy --spicevmc channelid=128,handler=vte
> # just an example
>

Right, although I propose that as soon as we've a vte channel handler, we
reserve channel-ids for monitor and serial-console channels, so that the
client will know how to handle these without needing special cmdline
options, and can even represent them in its menu with sensible entries
like: "show qemu monitor" "show serial console X" (we can have
multiple serial consoles)

Regards,

Hans