Subject: Re: towards loadable USB drivers
To: None <M.Drochner@fz-juelich.de>
From: M. Warner Losh <imp@bsdimp.com>
List: tech-kern
Date: 05/21/2005 08:32:15
In message: <200505191932.VAA0000043859@zel459.zel.kfa-juelich.de>
            Matthias Drochner <M.Drochner@fz-juelich.de> writes:
: Checking what obstacles are in the way to loadable USB drivers
: I found one implementation detail which makes it unnecessarily
: hard -- the way "subdevices" are handled.
: 
: "subdevices" are logical devices (in terms of the NetBSD autoconf
: framework) which are handling one physical USB device. There
: is the possibility that one USB device provides multiple
: "interfaces" (that's a USB term here) which different drivers
: can attach to.
: 
: These are managed in a NULL-terminated list. That's bad because
: with loadable drivers a device (in terms of autoconf) can disappear
: when the driver is detached, independantly of hardware events.
: We could make that an array with known length, or a linked list.
: I've tried the former just to get an impression how invasive
: this gets. Patch appended, just to give an impression -- there
: is more to do unfortunately.
: Comments?

This is a big can of worms.  I'm trying to sort it out in FreeBSD
where the usb stack and FreeBSD's driver model don't match very well.
More on this below.

It's worse than that.  Consider the following scenario:

Device Fred is a specialized device needing its own driver.  However,
it also presents different interfaces to the system that the standard
drivers recognize.

The current code gives all drivers a chance to attach to Fred, the
whole fred, and if that fails, the individual interfaces are presented
to drivers.

When you can load a driver at any time, this means that if fred isn't
loaded when you start, then you'll have to make sure that all the
sub-interfaces are detached if Fred's match routine matches the whole
device.  This is a little more complicated than the usual 'ugen
gobbles all' case, I believe, since there are more drivers than just
ugen.

: And while we are here: is there any use of the udi_devnames[]
: thing?

I think it may be used for the usbdevs program to get data out of the
kernel.

Warner