Re: The magical mystical changing ethernet interface order

[Kai Germaschewski]

On Thu, 8 May 2003, David S. Miller wrote:

>    From: Alan Cox <[e-mail]>
>    Date: 08 May 2003 15:55:31 +0100
> 
>    Unfortunately for the ISA driver code we *have* to rely on link
>    order or rip out the __init stuff and use Space.c type hacks.
>    
> I do no argue that needing an invocation order is bogus.
> I merely disagree with the way we're trying to achieve it.

For one, the current way works, i.e. the linker doesn't reorder, and if it 
did, a whole lot of stuff would break. If the linker changed all of a 
sudden, there actually exists a section flag which tells it to not reorder 
things within that section. We're not currently setting this flag (and I 
don't even know how to do it), but if it becomes necessary, it'd be an 
option.

That said, the current way of doing things is surely not perfect. This 
discussion was on l-k before, IMO it's too late now for such big changes, 
but it should be kept in mind for 2.7.

There are different cases:

o Lots of init order dependencies are reflected in module load order (an 
  ISDN hardware driver like hisax.o calls register_isdn(), which is 
  exported from isdn.o. So when using modules, isdn.o must be loaded and
  thus initialized before any hardware driver. When these modules
  are built-in, no such restriction currently exists and things can
  go wrong - this is fixable, the dependency information just needs to be
  figured and used - there existed an initial patch for it.

o Lots of cases where we don't really call about the order but want it
  to remain constant, just so that network interfaces don't magically
  switch names etc. (Yes, other solutions like MAC exist, but it's still
  really inconvenient to have stuff change randomly). For this case,
  I think relying on link order as we currently do is totally fine.

o Some more complicated dependencies, as in "acpi needs pci which needs 
  arch_pci and the driver model to be initialized" or whatever.

> You don't need Space.c magic, the linker in binutils has mechanisms by
> which this can be accomplished and we already use this in 2.5.x
> 
> Have a peek at __define_initcall($NUM,fn), imagine it with one more
> argument $PRIO.  It might look like this:
> 
> #define __define_initcall(level,prio,fn) \
>         static initcall_t __initcall_##fn __attribute__
>         ((unused,__section__ ("\.initcall" level "." prio ".init"))) = fn
> 
> Use the 'prio' number to define the ordering.  The default for
> modules that don't care about relative ordering within a class
> use a value like "9999" or something like that.

Using a number to get the latter case right, be it a prio or a level, is 
just a hack, we want to explicitly know what we depend on being 
initialized first in this case.

Someone, rusty IIRC, had a patch which allowed to explicitly list init 
order dependencies, again this didn't get merged and I think it's too late 
now, but it should be kept in mind for 2.7. Adding another 
numerical priority level is IMO only yet another hack instead of doing it 
right.

--Kai