On Tue, 2 Sep 2008, Matthew Wilcox wrote:

quoted text
> Here's a document for discussion.  No code yet, though I'm quite willing
> to modify the current usbip code to follow this new protocol.  Just a
> matter of time.
> 
> http://www.kernel.org/pub/linux/kernel/people/willy/usbip/usbip-protocol-draft-1

Most of your decisions look good to me.

quoted text
> 'get version' is now a call rather than including a version field in
> every request.

Have you given any thought to forward compatibility?  I imagine it's 
too early to worry about that yet.

quoted text
> Devices are now referred to as an ascii string rather than an encoded
> 4-byte quantity.  This helps userspace configure the device and lets us
> interoperate with other OSes that might want to implement this protocol.

Is this string intended to be meaningful to a human?  Or could it be 
nothing more than an ASCII version of the device structure's address?

quoted text
> I've split 'cmd_submit' into four commands (control, data, isoc, irq).
> That gives us the ability to make 'data' very small.

A number of important commands are missing.  Clear-Halt springs to
mind, as do Reset-Device, Set-Configuration, and Set-Interface.

quoted text
> Instead of transmitting the device number in every command, we now bind
> each socket to a particular device.  This was already what happened,
> so it was just overhead.

This isn't mentioned in your document.  There are "claim device" and 
"release device" calls, but it doesn't say anywhere that only one 
device can be claimed at a time.  Nor is there a status code for "No 
device claimed".

quoted text
> There's no need to respond with the call number to each call -- the
> caller should be using the call identifier to find out what type of
> call it was.  Often the implementation will issue a command and then
> wait for the response, so even that is unnecessary.

What happens when your protocol is used with a non-reliable transport?  
Who is responsible for retransmissions/acknowledgements?

quoted text
> Replying with the status is vital.

The reply to a submit call will be sent when the USB transfer is
complete.  Suppose the transfer takes a long time.  How does the client
tell the difference between a long-running transfer and an unreceived
submit?  Do you essentially assume that all protocol transfers are
reliable?

There isn't any field in the submit reply to report the status of the 
transfer (as opposed to the status of the submission).  How do errors 
like -EILSEQ get reported back to the client?

quoted text
> I decided to make the 'call' value 32-bit (instead of 8-bit) to make
> everything align nicely.  Then I wanted to slim down the data command
> call, so I tucked the endpoint and direction in there too.

What about the extra flags that go with URB submissions?  
URB_NO_INTERRUPT and URB_SHORT_NOT_OK might well be useful, 
URB_ZERO_PACKET is certain to be needed, and even URB_ISO_ASAP might 
come in handy.

quoted text
> I have no experience with isosynchronous transactions, nor interrupt
> transactions, so I decline to define them at this moment.

It will not be possible to support all the features of Linux's USB 
stack for these types of transfers (I'm referring to the way the 
bandwidth isn't released if a new URB is submitted during the 
completion callback).

Both types will require an additional "interval" field for submission,
and Isochronous will require "start_frame", "number_of_packets", and a
list of packet descriptors as well.  It also will require a status and
length for each component packet in the reply.

In the unlink call, what is the "seqnum" field?  Is it supposed to be 
the call identifier of the corresponding submit call?

Alan Stern

--
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/