[lkml]   [2000]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: test[9-10] USB depmod unresolved symbols
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.


greg k-h

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 12:45    [W:0.069 / U:1.892 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site