On Tue, 2 May 2006 15:39:49 -0400, Glenn Maynard <[EMAIL PROTECTED]> wrote:
> Sorry for the silly question, but: if this has to be specified explicitly
> for devices in unusual_devs, why does it not for ordinary devices (which
> aren't in unusual_devs)? That is, why can't this flag be derived (from
> the device and the unusual_devs entry)?
Currently, we have two cases: when libusual is disabled (which is what
those who want to save RAM use), and when it's enabled.
If libusual is not present, ub uses this table:
static struct usb_device_id ub_usb_ids[] = {
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_SCSI, US_PR_BULK) },
{ }
};
This specifies the devices which speak the Transparent SCSI over Bulk,
and thus excludes RBC, UFI, 8070 protocols, CB/CBI transport, etc. etc. etc.
It also excludes devices with malformed descriptors.
However, absent libusual, ub will happily try to drive devices with
phantom LUNs, devices reporting wrong size, devices choking on INQUIRY -
with varying degree of success. I imagine that for an arcade, most
of this makes no difference: INQUIRY is never issued by ub, phantom
LUNs are present but not mounted, size is encoded in pre-existing
partitioning, and so on.
If libusual is present, all three drivers refer to the same copy of
the table, which has .device_info field locked to usb-storage.
This prevents any disagreements between them. The table looks
like this after the macro expansion:
struct usb_device_id storage_usb_ids [] = {
{ .match_flags = ((0x0001 | 0x0002) | (0x0004 | 0x0008)),
.idVendor = (0x03eb), .idProduct = (0x2002),
.bcdDevice_lo = (0x0100), .bcdDevice_hi = (0x0100),
.driver_info = (US_FL_IGNORE_RESIDUE)|((1)<<24) },
..................
{ .match_flags = (0x0080 | 0x0100 | 0x0200), .bInterfaceClass = (8),
.bInterfaceSubClass = (0x05), .bInterfaceProtocol = (0x50),
.driver_info = ((1)<<24) },
{ .match_flags = (0x0080 | 0x0100 | 0x0200), .bInterfaceClass = (8),
.bInterfaceSubClass = (0x06), .bInterfaceProtocol = (0x50),
.driver_info = ((0)<<24) },
{ }
};
Again, everything except the very last entry is set to usb-storage,
and the last entry is exactly the same which ub carries.
So, why won't we simply encode the knowledge about things which
are safe for ub in a monstrous if-if-if statement? I considered
this, but found it a) not safe enough, b) clumsy, c) redundant.
The main purpose of libusual is to remove any conflicts and uncertainty.
It's either ub, or usb-storage, but not both (or neither) with any device.
Also, the need to encode the presence of an initialization function
results in this:
+++ linux-2.6.17-rc2-lem/drivers/usb/storage/libusual.c 2006-04-26
01:14:22.000000000 -0700
@@ -59,6 +59,21 @@ struct usb_device_id storage_usb_ids []
MODULE_DEVICE_TABLE(usb, storage_usb_ids);
EXPORT_SYMBOL_GPL(storage_usb_ids);
+#define UNUSUAL_DEV(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax, \
+ vendorName, productName,useProtocol, useTransport, \
+ initFunction, flags) \
+ sizeof(#initFunction)>5
+
+#define USUAL_DEV(useProto, useTrans, useType) 0
+
+char storage_init_needed [] = {
+# include "unusual_devs.h"
+ (char)-1 /* Terminating entry */
+};
+
+#undef USUAL_DEV
+#undef UNUSUAL_DEV
+
Cute, isn't it? I thought better to avoid it.
-- Pete
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
