[Spice-devel] RFC spicevmc chardev backend

[Gerd Hoffmann]

   Hi,

> +CharDriverState *qemu_chr_open_spice(QemuOpts *opts)
> +{
> +    CharDriverState *chr;
> +    SpiceCharDriver *s;
> +    // TODO: use path to determine which virtual channel to connect
> +    // to. Right now it's hard coded to the VDI_PORT (for vdagent)
> +    const char* name = qemu_opt_get(opts, "name");
> +    uint32_t debug = qemu_opt_get_number(opts, "debug", 0);
> +
> +    if (strcmp(name, "vdiport") != 0) {
> +        fprintf(stderr, "spicevmc: only vdiport is supported for name\n");
> +        return NULL;
> +    }

Ok.  Here it starts to become interesting ...

Today we have one channel, for vdagent.

We want move to a model where we can have multiple channels.  Certainly 
makes sense.  But that must be handled all the way through the stack. 
With multiple channels used for multiple purposes we will need:

   (1) Some way to specify which protocol we are running here.
       - vdagent protocol
       - smartcard protocol
       - clipboard protocol (I still think clipboard should be separate
         from vdagent, especially if we have multiple channels anyway
         for other reasons).
       - plain terminal (when redirecting a serial line for example).
       - usb redirect
       - whatever else ...
   (2) Some way to identify the channels.  Just the protocol isn't
       enougth as you could redirect multiple serial lines or forward
       multiple usb devices.

This is needed for both libspice-server api and the spice network 
protocol.  Today neither the libspice-server api nor the network 
protocol can handle this as far I can see.

Luckily the vdi port is in spice-experimental.h so we can fix it without 
too much headache.

The network protocol needs an extention too.  We can either add a new 
SPICE_MSG_MAIN_VMC_DATA message with additional fields and deprecate 
SPICE_MSG_MAIN_AGENT_DATA.  Or take a completely different route and 
open a new channel for each vmc, so we don't have to overload the main 
channel with all that data.

cheers,
   Gerd