Hi,
The plan in short:
1) The client decides to redirect a certain usb device
(be it through user interaction, or based on admin configuration /
instructed by the controller)
2) The client opens a new usbredir spice channel to the spice-server for
this (1 channel per device)
3) spice server asks qemu to dynamically create a new spicevmc chardev
+ usb-redir device couple (this is the part that needs the API extension).
4) spice-server forwards requests from the channel to the chardev and
visa versa
5) On of the first messages send by the client is a usbredir_device_connect
message, the usb-redir device checks info in this message (usb-id,
device class) against a configured filter which determines what kind of
devices can be redirected (if any), and may decide to destroy the usb-device
before it is ever attached to the guest. The server can notice this
by spice_server_remove_interface getting called for the chardev.
6) on channel close the usb-redir device is destroyed, this also takes care
of closing the chardev (which it owns after qdev initalization has
completed)
Questions:
a) Good plan / bad plan ?
b) since the creation / destruction of the chardev + usb-redir device
couple is triggered by the spice-server I propose adding the following
2 new functions to SpiceCoreInterface:
void *(*create_usbredir_device)(void);
void (*destroy_usbredir_device))(void *device);
create_usbredir_device returns either an opaque handle,
or NULL on error; on success qemu_spice_add_interface() will
have been called with a spicevmc chardev interface before this
function returns
destroy_usbredir_device destroys the device in question.
Comments anyone ?
Regards,
Hans
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
