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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
