Greg: As a result of recent activity, I've been thinking about ways to eliminate the usb-storage unusual_devs.h file and related blacklist information in the kernel. There are lots of problems associated with these things: they get old and out-of-date, they contain incorrect information, and most importantly each entry takes up space in everybody's kernel even if only one person in the whole world might use the device it describes.
(For an example of one type of problem that can arise, see http://marc.theaimsgroup.com/?l=linux-usb-devel&m=108855733410870&w=2 and the followup thread http://marc.theaimsgroup.com/?l=linux-usb-devel&m=108860641103374&w=2 This is an entry that almost certainly should be removed.) I don't know if anyone else has come up with a proposal to improve matters, so here are my ideas... It's immediately obvious that these blacklist databases don't belong in the kernel at all; they should be in userspace where they can grow as large as needed and can easily be changed and updated. The problem then becomes how to communicate the information to device drivers at runtime. The most serious difficulty is that when a new device is detected, it's not possible for even a hotplug script to send the necessary information in time for a driver to use it, because the driver-model core doesn't pause before probing drivers. My proposal includes a partial solution for this. What's needed is a resident, in-kernel database that only contains entries for devices that actually exist in the system (or will exist soon, or used to exist but haven't yet had their entries removed). This is exactly the approach the hotplug system implements for devices and drivers; I'm just adding blacklists into the picture. Something like this already exists in the SCSI core. The pseudofile /proc/scsi/scsi_deviceinfo contains blacklist information for many devices. There's a large list compiled into the SCSI driver, and users can add entries at any time by writing to the file. So let's take this idea and improve on it. The driver-model core could maintain a database where each record consists of three null-terminated strings: driver name, device ID, and data The contents of this database can be exposed through procfs or a similar mechanism. The driver-model core would only use the first two fields for matching entries; a new entry that matches an existing entry in the driver name and device ID fields would overwrite it. Each device driver would be able to iterate over all the entries which match its name, and interpretating of the device ID and data fields would be entirely up to the driver. Since the data can be an arbitrary character string, there is great flexibility for encoding and storing information. (An important point is that this information doesn't really belong in sysfs, because there needs to be entries for drivers that aren't currently loaded in the kernel. That's the only way to guarantee that when the driver _is_ loaded the information will be available.) (Another somewhat tangential point: We might want to include whitelist information too, in the sense that the hotplug system ought to be able to cause a driver to be probed for a particular device even if the normal matching criterion fails. Among the entries in the database could be items that tell a bus driver to match a particular device to a particular device driver.) Presumably the hotplug system would be used to populate this resident database, based on a large set of known entries stored in a file. The system would useable even in the absence of hotplug support, however. All that's needed is a utility that at some early stage during the boot process would copy into the resident database a short file containing the entries for devices currently attached to the system. Adding support for new devices would be as simple as adding a new line to a hotplug file and letting the hotplug system load the new information when the device is first detected. That's a whole lot easier than editing some kernel source or applying a patch, then rebuilding and reloading a driver module. Although this might not work the very first time a new device is plugged in (because the driver might be loaded before the hotplug program can load the appropriate information into the kernel), there shouldn't be any problems after that. The hotplug system, or some other related hardware maintenance program, would remember that the new device is present and would automatically load its database entry at future boot-ups. This mechanism should be useable by almost any sort of driver. And by moving the majority of the database out of the kernel it should provide a great improvement in memory utilization and maintainability. Comments? Would this be a good sort of thing for 2.7? Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
