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

[Alon Levy]

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 at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel