[Spice-commits] spice/enums.h

[Hans de Goede]

 spice/enums.h |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

New commits:
commit 72b225b9fc4bf190bc3c0036e90617bd6372b05b
Author: Hans de Goede <hdegoede at redhat.com>
Date:   Thu Aug 25 11:12:34 2011 +0200

    Change usbredir messages to spicevmc messages
    
    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>

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 */