Re: test[9-10] USB depmod unresolved symbols

[Greg KH <greg@wirex.com>]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

Thanks Keith for that detailed description of what is going wrong, I
would have never figured that out.

On Sat, Oct 28, 2000 at 12:29:39PM +1100, Keith Owens wrote:
> 
> I will add LINK_FIRST and LINK_LAST to kbuild this weekend and
> reinstate the missing lines in drivers/usb/Makefile.  What I need from
> the USB group is a documented (i.e. *why* is this order required)
> definition of what needs to be linked first into usbdrv.o, and somebody
> we can query if there are problems in the future.  It will probably be
> as simple as

Yeah, a valid reason for LINK_FIRST and LINK_LAST!

I'll try my hand at the wording. Randy, does this look acceptable:

# usb.o contains __init usb_init which must be executed before all
# other usb __init routines, the remaining usb __init routines can be
# executed in any order.  Execution order of __init routines depends
# on link order so usb.o must be linked first.  Otherwise, the
# individual drivers will be initialized before the hub driver is,
# causing the hub driver initialization sequence to needlessly probe
# every USB driver with the root hub device.  This causes a lot of
# unnecessary system log messages, a lot of user confusion, and has
# been known to cause a incorrectly programmed USB device driver to
# grab the root hub device improperly.
#     Greg Kroah-Hartman, 27 Oct 2000

LINK_FIRST := usb.o

> but you know better than I what the required order will be and why.
> Are there any other link order problems in USB?

That's the only known link problem for the USB drivers.

Thanks,

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]