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---------------------------
On Wed, May 07, 2003 at 03:18:19PM -0000, Dick Streefland wrote:
> 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".
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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Russell King <[email protected]> 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.
Andrew Morton wrote:
> Russell King <[email protected]> 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
[email protected]
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 <[email protected]>
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.
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:
> 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.
I was thinking of a different implementation, that I just made sure to forgot
as this one seems _much_ nicer indeed.
- Arnaldo
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...
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
In article <[email protected]>,
David S. Miller <[email protected]> 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
On Thu, 8 May 2003, 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.
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
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
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 `-------------------------------------------------
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
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)
On 08 May 2003 22:46:26 +0100 Alan Cox <[email protected]> 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
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
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~
Ray Lee <[email protected]> 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
[email protected] (@ @) http://www.altium.com
--------------------------------oOO--(_)--OOo---------------------------
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 |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
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 <[email protected]>
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