Re: The magical mystical changing ethernet interface order

Re: The magical mystical changing ethernet interface order

[Jean Tourrilhes]

Russell King wrote :
> 
> Does anyone know if there's a reason that the ethernet driver initialisation
> order has changed again in 2.5?
>
> Its rather annoying when your dhcpd starts on the wrong interface.

David S. Miller wrote
> Any reliance on link ordering is broken and needs to be fixed.

	I fully agree with David, this problem goes beyond the link
order.
	Since 97, I've been figthing this issue with my laptop. I've
got various Pcmcia card (Ethernet and Wireless), as well as PCI and
ISA Ethernet cards in the docking station. Depending on which
configuration the laptop is started in, eth0 could be any Pcmcia card
or any ISA/PCI card in the docking station.
	With USB in the picture, things are even more dynamic. And no
careful kernel link order mechanism will ensure that eth0 is the same
device.
	So, let's get rid of the link order "fix", because this
address only a small subset of the problem. Let's fix the real problem
which is that eth0 can't map any specific hardware device, and the
device name is totally arbitrary and meaningless.

Randy.Dunlap wrote :
> 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

	Currently this feels like a kludge, because not fully
inegrated, but goes in the right direction.
	Actually, it's pretty funny that the original Pcmcia package
got it right since the beggining (and Win2k as well), but
distributions took a step backward from that when integrating Pcmcia.
	My belief is that configuration scripts should be specified in
term of MAC address (or subset) and not in term of device name. Just
like the Pcmcia scripts are doing it.
	And let's go the extra mile : ifconfig should accept a MAC
address as the argument instead of a device name. And in the long
term, just get rid of device name from the user view.

	Have fun...

	Jean

Re: The magical mystical changing ethernet interface order

[Eli Carter]

Jean Tourrilhes wrote:
[snip]
> Randy.Dunlap wrote :
> 
>>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
> 
> 
> 	Currently this feels like a kludge, because not fully
> inegrated, but goes in the right direction.
> 	Actually, it's pretty funny that the original Pcmcia package
> got it right since the beggining (and Win2k as well), but
> distributions took a step backward from that when integrating Pcmcia.
> 	My belief is that configuration scripts should be specified in
> term of MAC address (or subset) and not in term of device name. Just
> like the Pcmcia scripts are doing it.
> 	And let's go the extra mile : ifconfig should accept a MAC
> address as the argument instead of a device name. And in the long
> term, just get rid of device name from the user view.

Some network devices do not have a mac address on power-up and must be 
supplied one.

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------

Re: The magical mystical changing ethernet interface order

[Jean Tourrilhes]

On Thu, May 08, 2003 at 04:43:57PM -0500, Eli Carter wrote:
> Jean Tourrilhes wrote:
> [snip]
> >Randy.Dunlap wrote :
> >
> >>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
> >
> >
> >	Currently this feels like a kludge, because not fully
> >inegrated, but goes in the right direction.
> >	Actually, it's pretty funny that the original Pcmcia package
> >got it right since the beggining (and Win2k as well), but
> >distributions took a step backward from that when integrating Pcmcia.
> >	My belief is that configuration scripts should be specified in
> >term of MAC address (or subset) and not in term of device name. Just
> >like the Pcmcia scripts are doing it.
> >	And let's go the extra mile : ifconfig should accept a MAC
> >address as the argument instead of a device name. And in the long
> >term, just get rid of device name from the user view.
> 
> Some network devices do not have a mac address on power-up and must be 
> supplied one.
> 
> Eli

	For those devices there is little difference conceptually
between using ifname to bind them to a known name and using ifconfig
to set the MAC address : you need to set the MAC address prior to any
operation, and when it's done, you have a MAC address so you can deal
with it like any other device.
	Anyway, those devices are so rare that I would not optimise
for them, and I would tradeof a bit more sanity for usual device in
exchange to a few complications for unusual devices.
	And I'm also perfectly well aware that some devices such IrDA
devices and PPP devices doesn't have a fixed 48bit address so can't be
handled with the scheme I propose. But those devices are usually
handled in their own way.

	Have fun...

	Jean

Re: The magical mystical changing ethernet interface order

[Alan Cox]

On Iau, 2003-05-08 at 20:32, Jean Tourrilhes wrote:
> 	My belief is that configuration scripts should be specified in
> term of MAC address (or subset) and not in term of device name. Just
> like the Pcmcia scripts are doing it.
> 	And let's go the extra mile : ifconfig should accept a MAC
> address as the argument instead of a device name. And in the long
> term, just get rid of device name from the user view.

Current Red Hat supports naming interfaces by their mac address. That
keeps most people happy except some sparc and embedded users who have
one mac per host not per card (and yes that *is* allowed by the
802.x spec)

Re: The magical mystical changing ethernet interface order

[Randy.Dunlap]

On 08 May 2003 22:46:26 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

| On Iau, 2003-05-08 at 20:32, Jean Tourrilhes wrote:
| > 	My belief is that configuration scripts should be specified in
| > term of MAC address (or subset) and not in term of device name. Just
| > like the Pcmcia scripts are doing it.
| > 	And let's go the extra mile : ifconfig should accept a MAC
| > address as the argument instead of a device name. And in the long
| > term, just get rid of device name from the user view.
| 
| Current Red Hat supports naming interfaces by their mac address. That
| keeps most people happy except some sparc and embedded users who have
| one mac per host not per card (and yes that *is* allowed by the
| 802.x spec)

Yep, found it in IEEE Std 802-2001.  It's just not the recommended
method for device address assignment.

--
~Randy

Re: The magical mystical changing ethernet interface order

[Thomas Hood]

Ray Lee wrote:
> Jean Tourrilhes wrote:
>>         My belief is that configuration scripts should be specified in
>> term of MAC address (or subset) and not in term of device name. Just
>> like the Pcmcia scripts are doing it.
>
> Debian already supports this, integrated into the normal scheme for
> dealing with interfaces.

Yes.  Note that the names 'lan' and 'internet' in the example
are name of possible configurations, not "physical" interface names.
They are only used by the ifupdown package; they do not show up
in an "ifconfig" listing.  Thus, doing "ifup eth0=home-wireless-1"
brings up interface eth0 in the home-wireless-1 configuration.
What implements the ability to work in terms of MAC addresses is the
mapping script /path/to/get-mac-addr.sh.  When, e.g., eth0 comes up,
get-mac-addr.sh scans for the MAC address and outputs either the
name 'lan' or the name 'internet'; ifupdown then configures eth0
with either the "lan" configuration or the "internet" configuration.

(The configurations are called "logical interfaces" in the ifupdown
documentation.)

>	auto eth0 eth1
>	mapping eth0 eth1
>		script /path/to/get-mac-addr.sh
>		map 11:22:33:44:55:66 lan
>		map AA:BB:CC:DD:EE:FF internet
>	iface lan inet static
>		address 192.168.42.1
>		netmask 255.255.255.0
>		pre-up /usr/local/sbin/enable-masq $IFACE
>	iface internet inet dhcp
>		pre-up /usr/local/sbin/firewall $IFACE

-- 
Thomas Hood <jdthood@yahoo.co.uk>

Re: The magical mystical changing ethernet interface order

[Ray Lee]

Jean Tourrilhes wrote:
>         My belief is that configuration scripts should be specified in
> term of MAC address (or subset) and not in term of device name. Just
> like the Pcmcia scripts are doing it.

Debian already supports this, integrated into the normal scheme for
dealing with interfaces. Anyone running Debian can take a look at
/usr/share/doc/ifupdown/examples directory, the network-interfaces.gz
file contains sample /etc/network/interfaces stanzas for configuring
your interfaces via MAC address:

	auto eth0 eth1
	mapping eth0 eth1
		script /path/to/get-mac-addr.sh
		map 11:22:33:44:55:66 lan
		map AA:BB:CC:DD:EE:FF internet
	iface lan inet static
		address 192.168.42.1
		netmask 255.255.255.0
		pre-up /usr/local/sbin/enable-masq $IFACE
	iface internet inet dhcp
		pre-up /usr/local/sbin/firewall $IFACE

You can even do something like:

	iface wireless inet dhcp
		wireless_key 12345678901234567890123456

A sample get-mac-address.sh is in the same directory, though it has a
typo (missing a close paren -- I need to report that...). This same
scheme works for pinging some well-known host to determine where you
are, or using ARPs, or whatever. I use it on my laptop with PCMCIA
cards, works great.

Ray

Re: The magical mystical changing ethernet interface order

[Dick Streefland]

Ray Lee <ray-lk@madrabbit.org> wrote:
| Debian already supports this, integrated into the normal scheme for
| dealing with interfaces. Anyone running Debian can take a look at
| /usr/share/doc/ifupdown/examples directory, the network-interfaces.gz
| file contains sample /etc/network/interfaces stanzas for configuring
| your interfaces via MAC address:
| 
| 	auto eth0 eth1
| 	mapping eth0 eth1
| 		script /path/to/get-mac-addr.sh
| 		map 11:22:33:44:55:66 lan
| 		map AA:BB:CC:DD:EE:FF internet
| 	iface lan inet static
| 		address 192.168.42.1
| 		netmask 255.255.255.0
| 		pre-up /usr/local/sbin/enable-masq $IFACE
| 	iface internet inet dhcp
| 		pre-up /usr/local/sbin/firewall $IFACE

I just do:

	auto  net
	iface net inet static
		pre-up    nameif net 00:00:C0:4F:8B:F6  
		...

	auto  lan
	iface lan inet static
		pre-up    nameif lan 00:60:B0:EC:92:F9  
		...

-- 
Dick Streefland                      ////                      Altium BV
dick.streefland@altium.nl           (@ @)          http://www.altium.com
--------------------------------oOO--(_)--OOo---------------------------

Re: The magical mystical changing ethernet interface order

[Mr. James W. Laferriere]

	Hello Ray & All ,  While that RedHat/Debian/... have figured
	these out is really nice .  NOT one of those methods appears to be
	available for hand built distros .  Ie: there does not appear to
	be a standardised(tm) method to approach this difficulty through
	out all drivers (not just ethernet) .

	Could someone please point me to NON RedHat/Debian/... centric
	tool to determine the proper ethernet for now ?

	Modules are not an option for me here .  Imo: If this can be done
	with modules it should well be possible for staticly built
	drivers as well .  Tia , JimL

On Thu, 8 May 2003, Ray Lee wrote:
> Jean Tourrilhes wrote:
> >         My belief is that configuration scripts should be specified in
> > term of MAC address (or subset) and not in term of device name. Just
> > like the Pcmcia scripts are doing it.
> Debian already supports this, integrated into the normal scheme for
> dealing with interfaces. Anyone running Debian can take a look at
> /usr/share/doc/ifupdown/examples directory, the network-interfaces.gz
> file contains sample /etc/network/interfaces stanzas for configuring
> your interfaces via MAC address:
> 	auto eth0 eth1
> 	mapping eth0 eth1
> 		script /path/to/get-mac-addr.sh
> 		map 11:22:33:44:55:66 lan
> 		map AA:BB:CC:DD:EE:FF internet
> 	iface lan inet static
> 		address 192.168.42.1
> 		netmask 255.255.255.0
> 		pre-up /usr/local/sbin/enable-masq $IFACE
> 	iface internet inet dhcp
> 		pre-up /usr/local/sbin/firewall $IFACE
> You can even do something like:
> 	iface wireless inet dhcp
> 		wireless_key 12345678901234567890123456
> A sample get-mac-address.sh is in the same directory, though it has a
> typo (missing a close paren -- I need to report that...). This same
> scheme works for pinging some well-known host to determine where you
> are, or using ARPs, or whatever. I use it on my laptop with PCMCIA
> cards, works great.
> Ray
-- 
       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

The magical mystical changing ethernet interface order

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: The magical mystical changing ethernet interface order

[Dick Streefland]

Russell King <rmk@arm.linux.org.uk> 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
dick.streefland@altium.nl           (@ @)          http://www.altium.com
--------------------------------oOO--(_)--OOo---------------------------

Re: The magical mystical changing ethernet interface order

[Jeff Garzik]

On Wed, May 07, 2003 at 03:18:19PM -0000, Dick Streefland wrote:
> Russell King <rmk@arm.linux.org.uk> wrote:
> | Its rather annoying when your dhcpd starts on the wrong interface.
> 
> You can avoid this by assigning new interface names with "nameif".

We all know this :)

Nonetheless it's still a bug.

	Jeff

Re: The magical mystical changing ethernet interface order

[Randy.Dunlap]

On Wed, 7 May 2003 14:14:58 +0100 Russell King <rmk@arm.linux.org.uk> 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/cset@1.1042.19.12?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

Re: The magical mystical changing ethernet interface order

[Russell King]

On Wed, May 07, 2003 at 08:24:16AM -0700, Randy.Dunlap wrote:
> What version of 2.5?

2.5.69.

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

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: The magical mystical changing ethernet interface order

[Andrew Morton]

Russell King <rmk@arm.linux.org.uk> wrote:
>
> A wild stab in the dark, I'd think maybe the init ordering changed:

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.

Re: The magical mystical changing ethernet interface order

[Dave Hansen]

Andrew Morton wrote:
> Russell King <rmk@arm.linux.org.uk> wrote:
> 
>>A wild stab in the dark, I'd think maybe the init ordering changed:
> 
> 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
haveblue@us.ibm.com

Re: The magical mystical changing ethernet interface order

[David S. Miller]

On Wed, 2003-05-07 at 15:28, Dave Hansen wrote:
> 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:

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 <davem@redhat.com>

Re: The magical mystical changing ethernet interface order

[Alan Cox]

On Iau, 2003-05-08 at 13:05, David S. Miller wrote:
> 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.

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.

Re: The magical mystical changing ethernet interface order

[David S. Miller]

   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.

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

Re: The magical mystical changing ethernet interface order

[Arnaldo Carvalho de Melo]

Em Thu, May 08, 2003 at 07:54:38AM -0700, David S. Miller escreveu:
>    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.

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

Re: The magical mystical changing ethernet interface order

[Jeff Garzik]

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

	Jeff

Re: The magical mystical changing ethernet interface order

[Randy.Dunlap]

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

Re: The magical mystical changing ethernet interface order

[Jeff Garzik]

Randy.Dunlap wrote:
> I don't care what the exact implementation is, but anything except
> depending on link (tools) order is better than now IMO.

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

Re: The magical mystical changing ethernet interface order

[Kai Germaschewski]

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

Re: The magical mystical changing ethernet interface order

[Linus Torvalds]

In article <1052395526.23259.0.camel@rth.ninka.net>,
David S. Miller <davem@redhat.com> wrote:
>On Wed, 2003-05-07 at 15:28, Dave Hansen wrote:
>> 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:
>
>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.

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

Re: The magical mystical changing ethernet interface order

[Richard Henderson]

On Thu, May 08, 2003 at 05:05:26AM -0700, David S. Miller wrote:
> This is absolutely not guarenteed.  The linker is at liberty to reorder
> objects in any order it so desires, for performance reasons etc.

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~