On Fri, May 31, 2002 at 05:21:22PM -0700, Jean Tourrilhes wrote:
> I was trying to make the IrDA stack work when compiled in the
> kernel in 2.5.X (as opposed to modular). In 2.4.X, it sort of work,
> but whoever made changes to the IrDA init in 2.5.X obviously didn't
> bother to check what he was doing and check his changes.
> So, I was trying to fix that, and I found a problem with
> kernel link order.
It is possible that recent kbuild changes caused that.
[snip]
> As both the random driver and the irda drivers are at the same
> init level, there is no way to enforce those dependancies. Currently,
> the IrDA drivers are loaded before the IrDA stack (== kaboom).
> Personally, I found it a bit strange the the random driver is
> initialised so late in the game when the whole networking code (at
> leasxt) depends on it.
>
> Please advise...
I remember something like this happened awhile back with the IDE driver,
trying to call a function in the cdrom driver before it was initialized.
There is a dirty workaround for this problem: Use a local static variable
to condition the modules' initialization, and make each module call
its init function inside every of its exported function, so this
'init-on-demand' will make sure the init code runs before the other
module's code.
BTW, does the new driver model addresses this problem?
--
Dan Aloni
[email protected]
On Sat, Jun 01, 2002 at 02:43:14AM -0500, Kai Germaschewski wrote:
> On Sat, 1 Jun 2002, Dan Aloni wrote:
>
> > > So, I was trying to fix that, and I found a problem with
> > > kernel link order.
> >
> > It is possible that recent kbuild changes caused that.
>
> I don't think so, I took extra care to leave it all the same. (Well,
> except for sound/, which is outside drivers/) It'd however surely be a
> good idea to go through it and document which dependencies there are.
Obviously Dan didn't bother to read my e-mail. The problem is
definitely not with kbuild. The problem is with the
__define_initcall() levels.
> W.r.t to the original problem I have to say I didn't really look into yet,
> but I think it makes e.g. a lot of sense to initialize networking earlier
> (subsys_initcall). We have initcall levels, using them right will help a
> lot. (The block subsystem is only __initcall a.k.a. driver_initcall as
> well, that's asking for problems at some point)
The problem is *not* the networking initialisation (I wish
people were *reading* my e-mails). The basic networking is initialised
early enough. The various networking stacks could be initialised
earlier, but I don't depend on them. Note that there might be a reason
to initialise networking after the file system, so to do that we might
need to insert a level between fs_initcall() and device_initcall().
The problem is with the initialisation of the random
generator. It needs to be done earlier.
> --Kai
Regards,
Jean
On Mon, Jun 03, 2002 at 10:14:47AM -0700, Jean Tourrilhes wrote:
> On Sat, Jun 01, 2002 at 02:43:14AM -0500, Kai Germaschewski wrote:
> > On Sat, 1 Jun 2002, Dan Aloni wrote:
> >
> > > > So, I was trying to fix that, and I found a problem with
> > > > kernel link order.
> > >
> > > It is possible that recent kbuild changes caused that.
> >
> > I don't think so, I took extra care to leave it all the same. (Well,
> > except for sound/, which is outside drivers/) It'd however surely be a
> > good idea to go through it and document which dependencies there are.
>
> Obviously Dan didn't bother to read my e-mail. The problem is
> definitely not with kbuild. The problem is with the
> __define_initcall() levels.
I did in fact read your e-mail. I was just suggesting something that is
drawn from previous experience concerning dependency problems with drivers
compiled in as non-modules. And in my e-mail I was suggesting a workaround
to make sure stuff gets initialized regardless of __initcall() levels.
--
Dan Aloni
[email protected]
On Sat, 1 Jun 2002, Dan Aloni wrote:
> > So, I was trying to fix that, and I found a problem with
> > kernel link order.
>
> It is possible that recent kbuild changes caused that.
I don't think so, I took extra care to leave it all the same. (Well,
except for sound/, which is outside drivers/) It'd however surely be a
good idea to go through it and document which dependencies there are.
There's surely stuff which could be cleaned up (Jeff, as you're CC'ed
anyway, look where tulip/ is linked in drivers/net/Makefile, I think that
could be straightened up a bit)
W.r.t to the original problem I have to say I didn't really look into yet,
but I think it makes e.g. a lot of sense to initialize networking earlier
(subsys_initcall). We have initcall levels, using them right will help a
lot. (The block subsystem is only __initcall a.k.a. driver_initcall as
well, that's asking for problems at some point)
--Kai