Hi,
On 01-07-15 18:13, Greg KH wrote:
On Wed, Jul 01, 2015 at 10:55:49AM -0500, Jeremy White wrote:
On 07/01/2015 12:44 AM, Greg KH wrote:
On Tue, Jun 30, 2015 at 10:34:25PM -0500, Jeremy White wrote:
1. Is the basic premise reasonable? Is Hans correct in asserting that an
alternate USB over IP module will be considered?
I have no idea, if it fully replaces the usbip functionality, I don't
see why that would be rejected. But why can't you just fix up usbip for
the issues you find lacking?
This is what Hans said 5 years ago: [1]
3) The protocol itself is far from ideal.
Number 3 is the big deal breaker for me. I've looked at the
(undocumented) protocol by sifting through the source. And it is
very low level, all it does is shove usb packets back and forth
over the network. It has no concept of configuration
setting (the docs say make sure the device is in the right
configuration before sharing it). No concept of caching things
like descriptors, active configuration, per interface alt setting,
etc.
Besides missing a lot of useful smarts the whole one packet at a
time approach does not really fly when it comes to isoc endpoints.
As there paper states, the vm-host / guest os drivers need to
make sure enough packets are submitted / queued at all time
to gap the network delay / fill the network pipe.
For iso endpoints it makes much more sense to have a start / stop
stream model, where the usb-host "pumpes" the urb ringbuffer and
sends out data received from the usb device to the vm-host
(isoc input endp case), or sends data received from the vm-host
(through a buffer to deal with network jitter) to the isoc output
endpoint.
This also halves the number of packets which need to be
send over the network, as their is no need for the vm-host to send
a request for each packet once an input stream has started / for
the usb-host to send an ack for each delivered packet for an ouput
stream. It would still send an error when an error occurs, but their
is no reason to ack all delivered packets. Given the delay
caused by buffering, etc. not being able to match up the error to
an exact packet is not important, as from the vm-host emulated usb
hc (host controller), the packet has long been delivered already.
Instead we will simply report the error to the guest os for the
next packet enqueued by the guest after receiving notification of
the error from the usb-host.
The protocol is now documented, so that part is out of date. I don't
see any evidence that the bulk of his other concerns have been
addressed, however.
Because no one has cared to. Now it seems you care, so I'd prefer to
see someone fix this up instead of adding another protocol that does
much the same thing.
I understand where you are coming from, but usbip is unfixable as it
has no concept of capability negotiation, protocol versioning or some such.
What we need is an usbip v2, and usbredir was written as that, and has been
used in production for years now for redirection of usb devices from
virtual-machine-viewers into qemu based virtual-machines.
I understand that having 2 protocols for one thing is undesirable in
general, but think of this as usb-mass-storage bulk transport vs uas,
or ipv4 vs ipv6 in some cases it just is necessary to do a new
better protocol.
When I designed and implemented usbredir usbip was pretty much dead, but it
got ressurected later. I've never spoken up on this and never attempted to
block usbip's promotion out of staging, as that seemed unfair since no-one
was working on a virtual-hcd driver for the usbredir protocol.
Likewise I think it is unfair if my not speaking up back then now blocks
an usbredir virtual-hcd driver from entering the kernel.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
