Am Montag, 19. Juli 2004 23:08 schrieb Alan Stern:
> 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.
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.
> > > (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?
Almost entirely. Usbfs' approach can be generalised.
> > > 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?
You can't ignore errors. A partially evaluated entry might be much worse
than nothing.
> > 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.
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
