Messages in this thread | | | Date | Thu, 8 May 2003 09:30:58 -0700 | From | "Randy.Dunlap" <> | Subject | Re: The magical mystical changing ethernet interface order |
| |
On Thu, 08 May 2003 12:26:53 -0400 Jeff Garzik <jgarzik@pobox.com> wrote:
| 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. | > | > 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. | | | Linus has traditionally resisted this, and pushed for the | link-order-defines-init-order bit. | | However, that was years ago. Patrick Mochel added the current | seven-levels-of-initcall, which is where the referenced | __define_initcall originated. | | I agree with you, and would prefer to move away from any dependence on | link order...
I don't care what the exact implementation is, but anything except depending on link (tools) order is better than now IMO.
-- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |