Re: USBIP protocol

["Steve Calfee" <stevecalfee@gmail.com>]

Hi all,

I have been looking at the USBIP stuff and don't understand the
generic probe issues.

In your second patch:
static struct usb_device_id stub_table[] = {
+#if 0
+	/* just an example */
+	{ USB_DEVICE(0x05ac, 0x0301) },   /* Mac 1 button mouse */
+	{ USB_DEVICE(0x0430, 0x0009) },   /* Plat Home Keyboard */
+	{ USB_DEVICE(0x059b, 0x0001) },   /* Iomega USB Zip 100 */
+	{ USB_DEVICE(0x04b3, 0x4427) },   /* IBM USB CD-ROM */
+	{ USB_DEVICE(0x05a9, 0xa511) },   /* LifeView USB cam */
+	{ USB_DEVICE(0x55aa, 0x0201) },   /* Imation card reader */
+	{ USB_DEVICE(0x046d, 0x0870) },   /* Qcam Express(QV-30) */
+	{ USB_DEVICE(0x04bb, 0x0101) },   /* IO-DATA HD 120GB */
+	{ USB_DEVICE(0x04bb, 0x0904) },   /* IO-DATA USB-ET/TX */
+	{ USB_DEVICE(0x04bb, 0x0201) },   /* IO-DATA USB-ET/TX */
+	{ USB_DEVICE(0x08bb, 0x2702) },   /* ONKYO USB Speaker */
+	{ USB_DEVICE(0x046d, 0x08b2) },   /* Logicool Qcam 4000 Pro */
+#endif
+	/* magic for wild card */
+	{ .driver_info = 1 },
+	{ 0, }                                     /* Terminating entry */
+};

You have changed your driver to a wild card for everything. Fine, it
makes sense, your probe routine should check if it wants a new device
and fail if it does not want it.

My problem is I am using the latest Suse enterprise linux which uses
kernel 2.6.18..... In that kernel the probes are done by the device
system and if a modprobe definition says the module is for this device
it gets loaded (by udev I think) and probed. fine. If the module is
already loaded the kernel probes the modules in the order they were
insmoded (if they say they want the particular VID/PID/CLASS/wildcard
etc.)

The problem is the probing is done by the kernel driver stuff and the
insmoding and user space intelligence is done by udev. Once a kernel
module is installed it must take all devices that match it's device ID
table.  Remember USBIP matches everything! That is because (at least
in the 2.6.18 kernel) the kernel driver stuff stops probing after a
probe fails. This is completely counter-intuitive to me, I would have
assumed that if a probe routine fails, the driver system would keep
going through the list looking for a driver that wants it.

Is this rule still true in the current kernels (I will care if and
when Novel/Suse updates its next enterprise addition).

So, at least in the latest Suse enterprise linux, these are the rules:
1) Any current driver will be probed in the order of insmod. If it
fails, the device will not have a driver
2) If there is no driver, udev will modprobe one and that process will
attach it to the device because all un-probed devices will be
reprobed.

I have not found a way to reprobe unclaimed drivers (and don't know
what order a reprobe would use - if USBIP rejects a device again
because it (USBIP_ is insmoded first it would still be unclaimed).

So to be more descriptive, say you want to do a remote USBIP flash
drive for drive "B", out of three drives, "A", "B","C". How can I
(from user space) enable this sequence? I can control the order of
module loading, (sort of).  I need usb_storage active twice and USBIP
active once for "B". This cannot not work with 2.6.18 - does it work
now?

Regards, Steve