Link order madness :-(

Link order madness :-(

[Jean Tourrilhes]

	Hi,

	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.

	The IrDA stack need to be initialised :
	AFTER :
		o the networking code (done in init/main.c)
		o driver/char/random.c (done via __initcall())
	BEFORE :
		o IrDA drivers (done via module_init())
		o IrDA higher protocols (done via module_init())

	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
least) depends on it.

	Please advise...

	Jean

Re: Link order madness :-(

[Dan Aloni]

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
da-x@gmx.net

Re: Link order madness :-(

[Kai Germaschewski]

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

Re: Link order madness :-(

[Jean Tourrilhes]

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

Re: Link order madness :-(

[Horst von Brand]

Jean Tourrilhes <jt@bougret.hpl.hp.com> said:

[...]

> 	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().

If you insert enough levels, you are in another form of madness.

There should be a way of saying "This must be initialized after this, and
before that" (the "before that" might perhaps be taken care of by the
"that" itself). Spiced with a few "barriers": "Networking inited", etc.
>From there the build system should figure it out by itself. tsort(1) on an
appropiate bunch of descriptive one-liners (extracted from the sources?)
should give the right initialization order, or error out.

Yes, I know this has been proposed before and been thrown out (for no good
reason, AFAICS)
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Link order madness :-(

[Nathan]

Horst von Brand wrote:

>Jean Tourrilhes <jt@bougret.hpl.hp.com> said:
>
>[...]
>
>  
>
>>	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().
>>    
>>
>
>If you insert enough levels, you are in another form of madness.
>
>There should be a way of saying "This must be initialized after this, and
>before that" (the "before that" might perhaps be taken care of by the
>"that" itself). Spiced with a few "barriers": "Networking inited", etc.
>>From there the build system should figure it out by itself. tsort(1) on an
>appropiate bunch of descriptive one-liners (extracted from the sources?)
>should give the right initialization order, or error out.
>
>Yes, I know this has been proposed before and been thrown out (for no good
>reason, AFAICS)
>  
>

Throwing in my $.02.  /etc/rc.d/* seems to have 100 levels (00 through 
99) and it (so far) appears to be pretty sane, from my perspective. 
 While 100 levels are perhaps too many, would it be more reasonable to 
have, say _early_initcall, _initcall, and _late_initcall for each of the 
categories (arch, fs, device, etc.)?  This would allow more granularity 
within levels so things needn't ever be improperly promoted out of their 
rightly-named level.  Prolly not, just thought I'd ask.

--Nathan

Re: Link order madness :-(

[Thunder from the hill]

Hi,

On Mon, 3 Jun 2002, Horst von Brand wrote:
> There should be a way of saying "This must be initialized after this, and
> before that" (the "before that" might perhaps be taken care of by the
> "that" itself). Spiced with a few "barriers": "Networking inited", etc.

Suggestion #1: make up an inittask table (bad idea, huge table) that gets 
freed on end of init.

Suggestion #2: each big subsystem (net, scsi, pcmcia, etc.) gets a lock 
that is engaged when starting, and is checked by the subsystems. The 
subsystems' init won't take place unless the parent subsystem is up. At 
end of init, these locks get freed.

Suggestion #3 (possibly the worst ever): let the subsubsystems be init'ed 
by the subsystems, using #ifdef'd calls...

I must leave now, sorry.

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: Link order madness :-(

[Dan Aloni]

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
da-x@gmx.net