The magical mystical changing ethernet interface order

Does anyone know if there's a reason that the ethernet driver initialisation order has changed again in 2.5?

In 2.2.xx, we had eth0 = NE2000, eth1 = Tulip In 2.4, we have eth0 = Tulip, eth1 = NE2000 And in 2.5, it's back to eth0 = NE2000, eth1 = Tulip

Both interfaces are on the same bus:

00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 30) 00:0d.0 Ethernet controller: Winbond Electronics Corp W89C940F

Its rather annoying when your dhcpd starts on the wrong interface.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Russell King <[email protected]> wrote:
| Its rather annoying when your dhcpd starts on the wrong interface.

You can avoid this by assigning new interface names with "nameif".

Dick Streefland                      ////                      Altium BV
[email protected]           (@ @)          http://www.altium.com
--------------------------------oOO--(_)--OOo---------------------------

We all know this :)

Nonetheless it's still a bug.

Jeff

On Wed, 7 May 2003 14:14:58 +0100 Russell King <[email protected]> wrote:

| Does anyone know if there's a reason that the ethernet driver initialisation
| order has changed again in 2.5?
| 
| In 2.2.xx, we had eth0 = NE2000, eth1 = Tulip
| In 2.4, we have eth0 = Tulip, eth1 = NE2000
| And in 2.5, it's back to eth0 = NE2000, eth1 = Tulip
| 
| Both interfaces are on the same bus:
| 
| 00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 30)
| 00:0d.0 Ethernet controller: Winbond Electronics Corp W89C940F
| 
| Its rather annoying when your dhcpd starts on the wrong interface.

What version of 2.5?

There was a patch 17 days ago by Chuck Ebbert (merged by akpm) that "fixed" PCI scan order in 2.5 to be same as 2.4. Comment in changelog says "Russell King has acked this change."

http://linus.bkbits.net:8080/linux-2.5/[email protected]?nav=index.html|ChangeSet@-3w

An alternative is to use 'nameif' to associate MAC addresses with interface names. See here for mini HOWTO:

http://www.xenotime.net/linux/doc/network-interface-names.txt

--
~Randy

2.5.69.

Yes, that affects the order of PCI devices on the global list when you have multiple PCI buses present. This machine has only one PCI bus, so is not affected by this issue.

Note that I haven't been running 2.5 kernels on NetWinders until recently, so I couldn't say when it changed. A wild stab in the dark, I'd think maybe the init ordering changed:

2.5.69 (System.map):

c0023ba4 t __initcall_ne2k_pci_init
c0023ba8 t __initcall_pcnet32_init_module
c0023bac t __initcall_eepro100_init_module
c0023bb0 t __initcall_tulip_init

2.4.19 (System.map):

c004ddd4 ? __initcall_tulip_init
c004ddd8 ? __initcall_vortex_init
c004dddc ? __initcall_ne2k_pci_init

2.2.18 (drivers/net/Space.c):

#ifdef CONFIG_NE2K_PCI
        {ne2k_pci_probe, 0},
#endif
#ifdef CONFIG_PCNET32
        {pcnet32_probe, 0},
#endif
#ifdef CONFIG_EEXPRESS_PRO100   /* Intel EtherExpress Pro/100 */
        {eepro100_probe, 0},
#endif
#ifdef CONFIG_LANMEDIA          /* Lanmedia must be before Tulip */
        {lmc_probe_fake, 0},
#endif
#if defined(CONFIG_DEC_ELCP) || defined(CONFIG_DEC_ELCP_OLD)
        {tulip_probe, 0},

#endif

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Well stabbed. The relative ordering of tulip and ne2k in drivers/net/Makefile got changed.

Maybe we should reorganise the 2.5 Makefile to copy the 2.4 Makefile's ordering. How pleasant.

I suspect the linker is at liberty to reorder these anyway.

The linker will order things in the final object in the order that you passed them. We depend on this for getting __init functions run in the right order:
http://groups.google.com/groups?selm=linux.kernel.27361.1016068035%40kao2.melbourne.sgi.com

Dave Hansen
[email protected]

This is absolutely not guarenteed. The linker is at liberty to reorder objects in any order it so desires, for performance reasons etc.

Any reliance on link ordering is broken and needs to be fixed.

David S. Miller <[email protected]>

That ahould keep you amused for a year or two. 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.

From: Alan Cox <[email protected]>
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.

The only magic is what to do with the vmlinux.lds scripts to handle this correctly. Are regular expressions allowed in the section names?

Em Thu, May 08, 2003 at 07:54:38AM -0700, David S. Miller escreveu:

I was thinking of a different implementation, that I just made sure to forgot as this one seems _much_ nicer indeed.

- Arnaldo

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

Jeff

On Thu, 08 May 2003 12:26:53 -0400 Jeff Garzik <[email protected]> wrote:

| David S. Miller wrote:
| >    From: Alan Cox <[email protected]>
| >    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

Well, The Leader Has Spoken, even though I disagree w/ him on this :)

Short term, addressing $subject, somebody needs to look into fixing up 2.5 net driver link order to match history. History is probably 2.2 in this case, if there is a disparity between 2.2 and 2.4.

Volunteers?

Jeff

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.

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

In article <[email protected]>,

No. Last time this came up rth spoke up and said that link ordering _is_ guaranteed.

The kernel depends on this in a lot more ways than just initcalls, btw:
all the exception handling etc also depend on the linker properly preserving ordering of text/data sections.

If the linker ever starts re-orderign things, we'll just either not upgrade to a broken linker, or we'll require a flag that disables the re-ordering.

End of discussion.

Linus

Not without some special flag it isn't. WAY TOO MUCH stuff depends on link order.

In any case, gnu ld DOES NOT reorder sections away from the order the objects were given on the command line.

r~