On Fri, Aug 29, 2008 at 08:02:24AM -0600, Matthew Wilcox wrote:
quoted text
> 
> I'm in the middle of implementing a userspace client for usbip and I
> strongly feel that the protocol needs to be changed before it is merged.
> 
>  - I'm unconvinced that TCP is the correct protocol to be running this over.
>    I understand the reluctance to use UDP, but the protocol is fundamentally
>    packet-based.  If TCP is used, the delimitation of packets within the
>    stream needs to be much more robust.  I've managed to wedge the VHCI driver
>    a number of times in ways that just wouldn't be possible if we were using
>    a packet protocol instead of a stream protocol.

USB is fundamentally packet-based, so it kind of fits very well.

quoted text
>  - Endianness.  This is a mess.  The usbip protocol is big-endian, but the
>    encapsulated usb protocol is little-endian.  This doesn't matter to the
>    people who are just tunnelling usb from one computer to another, but for
>    someone implementing a usbip client, it's very confusing.

Then just document it, no big deal.
Yeah, the current code isn't the cleanest here (sparse throws up some
warnings), but it's not that much work to fix it up, it's on my todo
list.

quoted text
>  - The protocol needs an officially assigned port number.  Port 3240 is 
>    already assigned to Tony Matthews <tmatthews&triomotion.com> February
>    2002 (see http://www.iana.org/assignments/port-numbers)

Great, let's get a real number.

quoted text
>  - There are actually two completely different protocols in use.  First,
>    the usbipd daemon listens on port 3240, and handles device discovery.
>    When usbip successfully attaches to usbipd, both sides of the connection
>    pass the socket fd into the kernel and the protocol changes.
>  - The protocol sends a 48-byte packet header for every command (and every
>    response).  It's cunningly hidden as a union.

Is that a real problem?

quoted text
> I think the protocol would be immeasurably improved by going through the
> IETF RFC process and getting feedback from networking experts.  Failing
> that, I have some suggestions about how to improve it.  I was hoping to
> get my client finished before I started mucking with the protocol though.

Why mess with the RFC process, is that really necessary for something
like this?

Windows has had this for years, no need for a RFC there, and if we just
document this well, no need for one here either.

thanks,

greg k-h
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/