Am Dienstag, 20. Juli 2004 16:19 schrieb Alan Stern:
> On Mon, 19 Jul 2004, Oliver Neukum wrote:
>
> > Yes, preferably structured and well versioned. You'd deal with reports
> > like: "I am using an mm-kernel with Debian's blacklist .deb of XX/XX/XX
> > and this patch my friend Charly sent me which I partially applied by hand"
> > only to find out a week later that he forgot to remake his initrd.
> > Separating kernel and blacklist is a bad idea.
>
> 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.
> > > 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?
> >
> > Almost entirely. Usbfs' approach can be generalised.
>
> 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.
> > 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.
> > > > 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.
> >
> > True. But that doesn't make the existing interface a good idea.
>
> I wonder what James Bottomley would have to say...
>
> 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.
Regards
Oliver
-------------------------------------------------------
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
