From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Hans de Goede <hdegoede@redhat.com>, spice-devel@lists.freedesktop.org
Subject: Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?
Date: Wed, 1 Dec 2010 11:04:57 +0000 [thread overview]
Message-ID: <201012011104.57988.paul@codesourcery.com> (raw)
In-Reply-To: <4CF4ECAB.9010602@redhat.com>
> Hi,
>
> On 11/30/2010 12:32 PM, Alon Levy wrote:
> > On Tue, Nov 30, 2010 at 12:26:56PM +0100, Hans de Goede wrote:
> <snip snip>
>
> >> Then there would be multiple ways to add a virtual usb device using
> >> usb-net-redir.c to the virtual machine. One way of adding such a device
> >> could be starting a tcp/ip server on a machine with an interesting usb
> >> device, say 192.168.1.100:2222 and then in the monitor type:
> >> usb_add net:192.168.1.100:2222:[vid]:[pid]
> >> or:
> >> usb_add net:192.168.1.100:2222:[busnr]:[addr]
> >
> > Wouldn't you want to add a usb_add net:host:port that would just export
> > anything it has decided to export? or is this just the next step?
>
> The idea is one channel (one socket in this case), one device. This way the
> same server on the usb-host could export multiple devices, using one
> client connection per device. The server of course should in the end have
> some sort of security wrt which devices the vm-host can connect to and
> which not.
I don't think either of vid:pid or bus:address are a good idea for identifying
remote devices. The idea that the VM should need to know about the details of
the USB topology of the remote machine seems fundamentally wrong. It also
means that it's impossible to use devices that reset+reconnect themselves.
Instead I suggest just using a freeform string ID. For practical reasons we
probably want to restrict this to regular characters, like we do other ids
(i.e. [-_A-Za-z0-9]). This allows the device server to assign persistent,
meaningful names to devices. If you really want to allow the VM free reign of
devices on a machine you can just make it the server accept and parse names of
the form device_id_1234_5678 (for example).
For bonus points your protocol should include some way of enumerating the
available devices.
When tunneling over spice/vnc I'd expect the same id to be used. i.e.
net:<host:port>:[device_id]
spice:[sice_display]:[device_id]
vnc:[vnc_display>]:[device_id]
Paul
next prev parent reply other threads:[~2010-12-01 11:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20101129101727.2B64E2B679@zimbra14-e2.priv.proxad.net>
2010-11-29 14:33 ` [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice? François Revol
2010-11-29 15:47 ` Gerd Hoffmann
2010-11-29 15:10 ` [Spice-devel] " Frédéric Grelot
2010-11-29 16:35 ` Gerd Hoffmann
2010-11-29 17:37 ` Attila Sukosd
2010-11-29 17:49 ` Anthony Liguori
2010-11-29 18:07 ` Alexander Graf
2010-11-30 8:54 ` Gerd Hoffmann
2010-11-30 11:26 ` Hans de Goede
2010-11-30 11:32 ` Alon Levy
2010-11-30 12:23 ` Hans de Goede
2010-12-01 11:04 ` Paul Brook [this message]
2010-12-01 11:49 ` Hans de Goede
2010-12-01 12:12 ` Paul Brook
2010-11-29 16:05 ` François Revol
2010-12-01 13:34 ` [Libusb-devel] " Peter Stuge
2010-11-29 17:13 ` Paul Brook
2010-11-30 11:07 ` [Qemu-devel] Using usbip for usb network redirection (was RFC: usb redirection over the network, interesting outside of spice?) Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201012011104.57988.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=hdegoede@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=spice-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).