mirror of
https://gitlab.uni-freiburg.de/opensourcevdi/spice
synced 2025-12-27 07:29:32 +00:00
c030382abb
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 usbredir.c to spicevmc.c and changes the prefix of all functions / structs to match. This should make clear that the code is not usbredir specific. 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, they must start at the SPICE_CHANNEL_USER_DEFINED_START value (128). 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> |
||
|---|---|---|
| .. | ||
| tests | ||
| .gitignore | ||
| agent-msg-filter.c | ||
| agent-msg-filter.h | ||
| char_device.h | ||
| demarshallers.h | ||
| glz_encode_match_tmpl.c | ||
| glz_encode_tmpl.c | ||
| glz_encoder_config.h | ||
| glz_encoder_dictionary_protected.h | ||
| glz_encoder_dictionary.c | ||
| glz_encoder_dictionary.h | ||
| glz_encoder.c | ||
| glz_encoder.h | ||
| inputs_channel.c | ||
| inputs_channel.h | ||
| jpeg_encoder.c | ||
| jpeg_encoder.h | ||
| main_channel.c | ||
| main_channel.h | ||
| Makefile.am | ||
| mjpeg_encoder.c | ||
| mjpeg_encoder.h | ||
| red_bitmap_utils.h | ||
| red_channel.c | ||
| red_channel.h | ||
| red_client_cache.h | ||
| red_client_shared_cache.h | ||
| red_common.h | ||
| red_dispatcher.c | ||
| red_dispatcher.h | ||
| red_memslots.c | ||
| red_memslots.h | ||
| red_parse_qxl.c | ||
| red_parse_qxl.h | ||
| red_tunnel_worker.c | ||
| red_tunnel_worker.h | ||
| red_worker.c | ||
| red_worker.h | ||
| reds_gl_canvas.c | ||
| reds_gl_canvas.h | ||
| reds_sw_canvas.c | ||
| reds_sw_canvas.h | ||
| reds.c | ||
| reds.h | ||
| smartcard.c | ||
| smartcard.h | ||
| snd_worker.c | ||
| snd_worker.h | ||
| spice-experimental.h | ||
| spice-server.syms | ||
| spice.h | ||
| spicevmc.c | ||
| stat.h | ||
| zlib_encoder.c | ||
| zlib_encoder.h | ||