Re: USB init order dependencies.

[Jeff Garzik <jgarzik@mandrakesoft.com>]

Russell King wrote:
> 
> Dunlap, Randy writes:
> > David is entitled to his opinion (IMO).
> > And I dislike this patch, as he and I have already discussed.
> >
> > Short of fixing the link order, I like Jeff's suggestion
> > better (if it actually works, that is):  go back to the
> > way it was a few months ago by calling usb_init()
> > from init/main.c and making the module_init(usb_init);
> > in usb.c conditional (#ifdef MODULE).
> 
> However, that breaks the OHCI driver on ARM.  Unless we're going to start
> putting init calls back into init/main.c so that we can guarantee the order
> of init calls which Linus will not like, you will end up with a lot of ARM
> guys complaining.
> 
> Linus, your opinion would be helpful at this point.

Back when some of the initial USB initcall stuff started appearing,
there were similar discussions, similar problems, and similar
solutions.  I was also wondering how fbdev (which needs to give you a
console ASAP) would work with initcalls, etc.  At the time (~6 months
ago?), Linus' opinion was basically "if the link order hacking starts to
get ugly, just put it in init/main.c"  So, Randy really should be
calling the quoted text above "Linus' suggestion" ;-)

Putting a call into init/main.c isn't a long term solution, but it
should get us there for 2.4.x...  init/main.c is also the best solution
for ugly cross-directory link order dependencies.  I would say the link
order of foo.o's in linux/Makefile is the most delicate/fragile of all
the Makefiles...  touching linux/Makefile link order this close to 2.4.0
is asking for trouble.  Compared to that, adding a few lines to
init/main.c isn't so bad.

IMHO,

	Jeff


-- 
Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/