On Tue, 20 Jul 2004, Oliver Neukum wrote: > > Separating kernel and blacklist is no different in principle from > > separating kernel and device driver installation. Are you saying that the > > entire hotplug & udev system is a bad idea? > > No. The drivers are still part of the kernel. Separating device drivers > and core kernel would be a bad idea.
Drivers are a part of the kernel only in two senses: they reside in and execute in the kernel (unavoidably), and some of them are distributed as part of the kernel source. How do you feel about drivers that aren't part of the kernel source -- are they a bad idea? Furthermore, these blacklists we've been discussing are data, not executable code. Think of them as an extremely flexible variation of driver module parameters. Users can load modules with arbitrary parameter settings, subject to the limitations imposed by the modules themselves; is that so bad? > > Usbfs doesn't offer any way to say "Bind this device to the usb-storage > > driver". Anyway, for the point I was making the exact mechanism doesn't > > matter. The main idea was that driver probing decisions should be > > configurable from userspace but currently they aren't. > > Triggered from or configurable? That I would consider different things. Configurable, not triggered from. It's already possible to trigger binding in usbfs by the USBDEVFS_CONNECT ioctl, which tells the kernel to probe all unbound devices on the bus. What's missing is a way to tell the kernel that "Device d interface i should be probed in usb-storage even though bInterfaceClass != 0x08". > > > You can't ignore errors. A partially evaluated entry might be much worse > > > than nothing. > > > > That's a policy decision which can be left up to the individual driver. > > There's no reason the core should have to worry about it. > > Error handling. You should parse any addition to such a file immediately > and the core would have to handle that. No, only the driver parses it since the entry is meaningful only to the driver. And this doesn't take place immediately when the entry is added to the kernel's database; it takes place at the time the driver needs to consult the blacklist -- i.e., when the driver is probing a new device. > > But consider the alternative. Do you really think it's a good thing to > > accumulate a never-ending series of error-prone cruft in the form of > > blacklist entries permanently living in the kernel? > > Yes. The best of all bad alternatives. > That stuff is not really additional complexity. It doesn't really matter > whether there are one or 500 entries. The mechanism is important > and, while it is in the kernel, you can easily grep through it. > If you took your idea to its logical conclusion you'd rip device ids > from the kernel. In many cases that's right, the device IDs could be removed. I think we're mainly expressing differences of opinion about the difficulty of managing blacklists. It's true that with modern PCs the memory usage of these blacklists can be ignored (although that's _not_ true in smaller systems, like handheld or embedded devices). It's also true that managing blacklists is a painful nuisance. And when the blacklist is part of the kernel that nuisance is multiplied by the difficulty and slowness of changing _anything_ in the kernel. 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
