That's okay; I'm not on a deadline. :-)
It is unfortunate that these two words have been used in multiple ways,
with meanings that are sometimes only subtly different and sometimes
grossly conflicting.
Isn't it standard in networking circles for "server" to mean the system
running a daemon that waits for incoming connections and "client" to
mean the system running an on-demand program that initiates a
connection?
Okay, "controller" and "target". I'm not sure that "controller" is the
best word either, since it might be confused with "USB host
controller".
Hmmm. Above you said that the controller system runs a program named
"usbip" and the target system loads a module named "usbip". Since the
stub driver is the usbip _module_, it must run on the target (AKA
server). Right?
Yes; it is referred to as a "virtual root hub", or just "root hub" for
short. We didn't make this up; section 10.2.8 of the USB spec is
entitled "Root Hub".
FYI, the *hci-hcd modules are collectively known as "host controller
drivers", or HCDs for short. We USB guys sling that term around a lot
-- if you start using it too you'll impress other programmers. :-)
Right.
"Detaches" isn't a USB term. Do you mean it in the sense of a SCSI
initiator detaching from its target?
In any event, the answer is that each endpoint has several properties
associated with it (direction, type, maximum packet size, and so on),
and these properties have to be known by both the target's USB stack
and the target's USB host controller hardware. The hardware uses DMA
to access various in-memory data structures describing the I/O
operations it should perform, and the format and contents of these data
structures depends on the endpoints' properties. (To make matters
worse, the hardware will sometimes maintain an internal cache for parts
of the data structures and some of the properties; when the properties
change the cache must be flushed.)
With new configurations or altsettings you end up with a new set of
endpoints, or the same old endpoints with a new set of properties.
Thus the target really needs to know when these things change.
I suppose the controller system, as part of its normal initialization
procedure for new devices, would issue such a reset. This area is
still a little cloudy -- we know that the controller system shouldn't
treat a new USBIP device exactly the same as a new normal USB device,
but exactly what the difference should be has yet to be fleshed out.
We may even want to have some sort of method table with entries for
initialization, reset, suspend, resume, and clear-halt.
It happens in the HCD, not in the device.
There's more to it. The USB stack behaves qualitatively and
quantitatively differently in these two cases:
An URB completes, the completion handler returns, and then
a new URB is submitted.
A new URB is submitted either before the old one completes
or while the old URB's completion handler is running.
With USBIP it's not feasible for an URB queued on the controller
machine to be submitted as part of the target's completion handler
processing. If the URB was queued in the target's usbipd driver then
this would be feasible. And of course, if the URB was queued in the
target's HCD then no special treatment would be needed.
For relevant background information, read the kerneldoc for
usb_submit_urb() and usb_unlink_urb() in drivers/usb/core/urb.c.
Alan Stern
--
