Am Dienstag, 20. Juli 2004 17:51 schrieb Alan Stern:
> 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
And they have interesing interactions with the rest of the kernel.
Imagine having to figure out where to use GFP_NOIO in usbcore without
the sources of the sttorage driver available.
> part of the kernel source. How do you feel about drivers that aren't part
> of the kernel source -- are they a bad idea?
Yes.
> 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?
They are unelegant, but we live in the real world and some knobs are
needed. It took serious effort to introduce datatypes into that system
and implement common parsers.
> > > 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".
Hm. Should be thought through carefully. Most drivers are definitely not
prepared for that.
> > > > 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.
IMHO that would be a serious flaw.
1) that means a separate parser for each driver and parsers can be quite
complicated code
2) there's no way to properly report errors
> > > 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
Yes. But not completely.
> 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.
Well, the paths to change anything in the kernel are at least well defined
and a change will be out there in a few weeks at most. And the kernel
is a selfcontained piece of code that can be easily upgraded. External
lists would not enjoy that advantage. In fact getting them out to users
would usually depend on distributions' release cycles.
There are a few technical issues, too.
a) backwards compatibility
b) code complexity - yet another entry point into drivers
c) it reminds me of putting the larva of a shell into kernel space
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
