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 <[email protected]> > --- > 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
