Re: The magical mystical changing ethernet interface order

Kai Germaschewski
2003-05-08T17:46:14Z

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

> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> 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