On Mon, 19 Jul 2004, Oliver Neukum wrote: > > the driver. Since the data can be an arbitrary character string, there is > > great flexibility for encoding and storing information. > > That is a problem not an advantage.
I don't think it's quite as bad as you seem to believe. After all, the data has to be stored somehow. Character strings provide an open-ended mechanism that can easily accomodate new pieces, and they are easily edited by hand. > > (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.) > > Can be done entirely in user space. Can it? I wondered about that. How does a userspace program tell the kernel to bind a particular device to a particular driver? Or more accurately, to pass that device to the driver's probe() routine? > > 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. > > Then you absolutely need an initrd. For some things (devices with quirks or blacklist entries that are present and used during boot-up) yes, you would. An alternative is to create a kernel source file that contains just some entries to initialize the database at boot time. It's the hotplug equivalent of building a driver into the kernel instead of building it as a module. You still get the advantage of _not_ including all the excess blacklist entries for devices you don't have. > It seems to me that you would be in for a lot of pain. > That "data" field is completely unstructured, so you end up keeping > device quirk description formats in sync. That would be entirely up to the individual device driver. I don't see any reason why it couldn't be done in a suitably compatible manner (log options not understood, ignore out-of-date options, etc.). Undoubtedly the parsing requirement would add a certain overhead to any driver using it. The question is, is it worthwhile for the gain in flexibility? > Introducing new interfaces to user space is not an unqualified good thing. Remember that there already is an existing precedent for this sort of thing in the SCSI driver. So this isn't really a _new_ interface; it's a generalization of an existing interface. 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
