How does "alias ethX drivername" in modules.conf work?

How does "alias ethX drivername" in modules.conf work?

[Mark Atwood]

I'm trying to figure out how "alias ethX" works in /etc/modules.conf

Is it some "magic" in depmod / modprobe? And how is the network
interface identifier then passed into the module when it loads?

A nice whitepaper or doc or a few pointers or handholding would be
apprecated.

-- 
Mark Atwood   | I'm wearing black only until I find something darker.
mra@pobox.com | http://www.pobox.com/~mra

Re: How does "alias ethX drivername" in modules.conf work?

[Chris Wedgwood]

On Fri, Aug 03, 2001 at 02:29:58PM -0700, Mark Atwood wrote:

    Is it some "magic" in depmod / modprobe? And how is the network
    interface identifier then passed into the module when it loads?
    
    A nice whitepaper or doc or a few pointers or handholding would be
    apprecated.

the kernel calls modprobe asking for the network device 'eth0',
modprobe uses the configuration file to map this to a module



  --cw

Re: How does "alias ethX drivername" in modules.conf work?

[Thomas Duffy]

On 04 Aug 2001 13:21:59 +1200, Chris Wedgwood wrote:

> the kernel calls modprobe asking for the network device 'eth0',
> modprobe uses the configuration file to map this to a module

so, what happens when you have two eth cards that use the same module?
in the isa land, the order you pass the io=0x300,0x240 would determine
which order the eth?'s go to...how about in the pci world?

-tduffy

Re: How does "alias ethX drivername" in modules.conf work?

[Chris Wedgwood]

On Fri, Aug 03, 2001 at 06:32:18PM -0700, Thomas Duffy wrote:

    so, what happens when you have two eth cards that use the same module?
    in the isa land, the order you pass the io=0x300,0x240 would determine
    which order the eth?'s go to...how about in the pci world?

when the pci module loads, it find all devices and registers them



  --cw

Re: How does "alias ethX drivername" in modules.conf work?

[Jim Roland]

It's a little simpler now.

Under 2.2 and 2.4, I have gotten away with doing the following (assuming 
the module does not require a port address or irq):
alias eth0 modulename
alias eth1 modulename

This assumes the kernel sees both cards (look in your kernel ring log, 
typically /var/log/dmesg).  If the entries are both there for eth0 and 
eth1 and irq and port addresses are correct, you're ready to go.  I have 
had no problems with DLink DE220s for example (NE2000 clones).

If it does not see the 2nd card (eth1), then go for something like 
"ether=0,0,eth1" in at the boot prompt (use the append option for LILO 
to make it permanent if you're using LILO).  If that does not work, then 
provide "ether=11,0x300,eth1" (example of IRQ11, IO address 300 hex). 
 The man page on bootparam will explain a little further.

The above was sometimes necessary for ISA, but the PCI world should 
require less intervention.



Thomas Duffy wrote:

>On 04 Aug 2001 13:21:59 +1200, Chris Wedgwood wrote:
>
>>the kernel calls modprobe asking for the network device 'eth0',
>>modprobe uses the configuration file to map this to a module
>>
>
>so, what happens when you have two eth cards that use the same module?
>in the isa land, the order you pass the io=0x300,0x240 would determine
>which order the eth?'s go to...how about in the pci world?
>
>-tduffy
>
>-
>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/
>

Re: How does "alias ethX drivername" in modules.conf work?

[Riley Williams]

Hi Thomas.

 >> the kernel calls modprobe asking for the network device 'eth0',
 >> modprobe uses the configuration file to map this to a module

 > so, what happens when you have two eth cards that use the same
 > module? in the isa land, the order you pass the io=0x300,0x240
 > would determine which order the eth?'s go to...how about in the
 > pci world?

One of my systems has SIX ethernet cards, these being three ISA and
two PCI NE2000 clones and a DEC Tulip. Here's the relevant section of
modules.conf on the system in question:

 Q> alias eth0 ne
 Q> options eth0 io=0x340
 Q> alias eth1 ne
 Q> options eth1 io=0x320
 Q> alias eth2 ne
 Q> options eth2 io=0x2c0
 Q> alias eth3 ne2k-pci
 Q> alias eth4 ne2k-pci
 Q> alias eth5 tulip

Best wishes from Riley.

Re: How does "alias ethX drivername" in modules.conf work?

[Thomas Duffy]

On 04 Aug 2001 20:35:37 +0100, Riley Williams wrote:

> One of my systems has SIX ethernet cards, these being three ISA and
> two PCI NE2000 clones and a DEC Tulip. Here's the relevant section of
> modules.conf on the system in question:
> 
>  Q> alias eth0 ne
>  Q> options eth0 io=0x340
>  Q> alias eth1 ne
>  Q> options eth1 io=0x320
>  Q> alias eth2 ne
>  Q> options eth2 io=0x2c0
>  Q> alias eth3 ne2k-pci
>  Q> alias eth4 ne2k-pci
>  Q> alias eth5 tulip
> 
> Best wishes from Riley.

ok, well this makes sense for the ISA cards.  I have card A in my hand,
I set the jumpers on it to an io port 0x340, stick it in slot X on my
computer, plug the wire into it from network 1, then I mentally can map
all the stuff together, so I know how to setup the network in Linux

eth0 == io 0x340 == card A == slot X in my computer == network 1

but, how can you tell the difference between eth3 and eth4 -- and
specify which *physical* card gets assigned to which virtual eth?
name...ie, how do I know which pci slot is which eth?  besides reading
the motherboard documentation and maybe learning which direction and how
the pci bus is ordered...which can differ between motherboard
manufacturers and BIOS's, etc, etc. 

and how do I change it if I don't like the default order (based off of
pci scan order).  what if I want card B, a pci card stuck in PCI slot Y
to be eth4?

hope this is clearer...

thanks,

-tduffy

Re: How does "alias ethX drivername" in modules.conf work?

[Riley Williams]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3312 bytes --]

Hi Thomas.

 >> One of my systems has SIX ethernet cards, these being three ISA
 >> and two PCI NE2000 clones and a DEC Tulip. Here's the relevant
 >> section of modules.conf on the system in question:

 >>  Q> alias eth0 ne
 >>  Q> options eth0 io=0x340
 >>  Q> alias eth1 ne
 >>  Q> options eth1 io=0x320
 >>  Q> alias eth2 ne
 >>  Q> options eth2 io=0x2c0
 >>  Q> alias eth3 ne2k-pci
 >>  Q> alias eth4 ne2k-pci
 >>  Q> alias eth5 tulip

 > ok, well this makes sense for the ISA cards. I have card A in my
 > hand, I set the jumpers on it to an io port 0x340, stick it in
 > slot X on my computer, plug the wire into it from network 1,
 > then I mentally can map all the stuff together, so I know how to
 > setup the network in Linux

 > eth0 == io 0x340 == card A == slot X in my computer == network 1

 > but, how can you tell the difference between eth3 and eth4 --
 > and specify which *physical* card gets assigned to which virtual
 > eth? name...ie, how do I know which pci slot is which eth?

That depends on the driver used to map those cards. Here's what I know
so far, mainly from experimentation:

 1. The ne2k-pci driver assigns cards in ascending ethernet address
    on this machine.

 2. On the same machine, when I had three tulip cards installed, the
    tulip driver assigned them in descending ethernet address.

 3. Both of the above results are independant of the order the cards
    are plugged into the PCI bus.

As a result, there is no simple answer to your question, and the
answer above probably depends to a large extent on factors other than
the card itself.

However, if the cards are controlled by different drivers, you can
influence the order they are detected in by your choice of entries in
modules.conf - in the example above, the ISA cards are always eth0,
eth1 and eth2, the NE2k-pci cards are always eth3 and eth4, and the
tulip card is always eth5, simply because that's what the said file
says.

 > besides reading the motherboard documentation and maybe learning
 > which direction and how the pci bus is ordered...which can
 > differ between motherboard manufacturers and BIOS's, etc, etc.

Remember that every ethernet card has an ethernet address assigned to
it, this being the "HWaddr" reported by `ifconfig` and (in theory at
least) these are all unique. All you need to do is to determine the
ethernet address of each of the cards in your system, then see which
interface has that ethernet address assigned to it, and you've found
the match...

 > and how do I change it if I don't like the default order (based
 > off of pci scan order). what if I want card B, a pci card stuck
 > in PCI slot Y to be eth4?

You could always add "options eth? io=0x????" lines for the PCI ports,
and hope the addresses you've specified don't get changed, but I'll
not guarantee this works as I've never tried it.

Probably of more use is to set the IP address for a particular
interface dependant on the ethernet address of the card supplying it.
The enclosed bash script should achieve that - it's basically the
`ifconfig` command with the port name replaced by its ethernet
address, but it only works for "eth?" ports. I've tried it on my
system, and it does the job it's designed to, but YMMV...

 > I hope this is clearer...

I hope this helps...

Best wishes from Riley.


[-- Attachment #2: /usr/local/sbin/ifmap --]
[-- Type: TEXT/PLAIN, Size: 1504 bytes --]

#!/bin/bash

###############################################################################
#
# This script provides a version of the `ifconfig` command that expects to
# see the ethernet address associated with a particular port, and performs
# the stated actions on whichever ethernet interface has the specified
# ethernet address. All actions associated with the `ifconfig` command are
# supported, and the only change in syntax is that the port name of "eth?"
# is replaced by the associated ethernet address.
#
# If no ethernet interface is found with the specified ethernet address, 
# this script uses a return value of 1, otherwise it uses a return value
# of 0.
#
###############################################################################

function assign() {
    local HW="$1" OK=Y
    declare -i N=0

    shift 1
    while [ $OK = Y ]; do
	if ! port eth$N ; then
	    if ifconfig eth$N up 2> /dev/null ; then
		if [ "`hwaddr eth$N`" != "${HW}" ]; then
		    ifconfig eth$N down
		else
		    ifconfig eth$N "$@"
		    OK=$?
		fi
	    else
		OK=0
	    fi
	fi
	N=$N+1
    done
    return $OK
}

function hwaddr() {
    ifconfig "$1" | grep "^$1" | tr ' ' '\n' | grep '[0-9A-F]:[0-9A-F]'
}

function port() {
    ifconfig | grep ^eth | fgrep "$1" > /dev/null
}

if [ $# -gt 0 ]; then
    if assign "$@" ; then
	echo No ethernet interface with address "$1" found. >&2
	exit 1
    else
	exit 0
    fi
else
    ifconfig
    exit 0
fi

Re: How does "alias ethX drivername" in modules.conf work?

[Andrzej Krzysztofowicz]

>  >> One of my systems has SIX ethernet cards, these being three ISA
>  >> and two PCI NE2000 clones and a DEC Tulip. Here's the relevant
>  >> section of modules.conf on the system in question:
> 
>  >>  Q> alias eth0 ne
>  >>  Q> options eth0 io=0x340
>  >>  Q> alias eth1 ne
>  >>  Q> options eth1 io=0x320
>  >>  Q> alias eth2 ne
>  >>  Q> options eth2 io=0x2c0
>  >>  Q> alias eth3 ne2k-pci
>  >>  Q> alias eth4 ne2k-pci
>  >>  Q> alias eth5 tulip
> 
> 
> However, if the cards are controlled by different drivers, you can
> influence the order they are detected in by your choice of entries in
> modules.conf - in the example above, the ISA cards are always eth0,
                                                         ^^^^^^
> eth1 and eth2, the NE2k-pci cards are always eth3 and eth4, and the
> tulip card is always eth5, simply because that's what the said file
> says.

Not always. You are wrong here, I'm afraid:

Lets assume that eth0-eth3 are not initialized at boot time and your init
scripts attempt to initialize eth4 ...

To avoid such problems one probably should add a lot of pre-install parameters
in modules.conf.

Andrzej

Re: How does "alias ethX drivername" in modules.conf work?

[Riley Williams]

Hi Andrzej.

First, what's with the crazy addresses for Linux-Kernel mailing list
and the various correspondants?

 >>>> One of my systems has SIX ethernet cards, these being three ISA
 >>>> and two PCI NE2000 clones and a DEC Tulip. Here's the relevant
 >>>> section of modules.conf on the system in question:

 >>>>  Q> alias eth0 ne
 >>>>  Q> options eth0 io=0x340
 >>>>  Q> alias eth1 ne
 >>>>  Q> options eth1 io=0x320
 >>>>  Q> alias eth2 ne
 >>>>  Q> options eth2 io=0x2c0
 >>>>  Q> alias eth3 ne2k-pci
 >>>>  Q> alias eth4 ne2k-pci
 >>>>  Q> alias eth5 tulip

 >> However, if the cards are controlled by different drivers, you can
 >> influence the order they are detected in by your choice of entries in
 >> modules.conf - in the example above, the ISA cards are always eth0,
 >                                                         ^^^^^^

 >> eth1 and eth2, the NE2k-pci cards are always eth3 and eth4, and the
 >> tulip card is always eth5, simply because that's what the said file
 >> says.

 > Not always. You are wrong here, I'm afraid:

 > Lets assume that eth0-eth3 are not initialized at boot time and
 > your init scripts attempt to initialize eth4 ...

Then I get an entry for eth4 in the `ifconfig` output, with NO entries
for `eth0` through `eth3`, exactly as expected.

Note that the `ifconfig` command refers to the interfaces by name, and
it's the settings in modules.conf that decide what type of interface
that name refers to. That mapping can't be changed by any interface
configuration or initialisation command, and the names used are those
as given.

 > To avoid such problems one probably should add a lot of
 > pre-install parameters in modules.conf.

What problems?

Best wishes from Riley.

Re: How does "alias ethX drivername" in modules.conf work?

[Andrzej Krzysztofowicz]

"Riley Williams wrote:"
>  >>>>  Q> alias eth0 ne
>  >>>>  Q> options eth0 io=0x340
>  >>>>  Q> alias eth1 ne
>  >>>>  Q> options eth1 io=0x320
>  >>>>  Q> alias eth2 ne
>  >>>>  Q> options eth2 io=0x2c0
>  >>>>  Q> alias eth3 ne2k-pci
>  >>>>  Q> alias eth4 ne2k-pci
>  >>>>  Q> alias eth5 tulip
> 
>  >> However, if the cards are controlled by different drivers, you can
>  >> influence the order they are detected in by your choice of entries in
>  >> modules.conf - in the example above, the ISA cards are always eth0,
> 
>  >> eth1 and eth2, the NE2k-pci cards are always eth3 and eth4, and the
>  >> tulip card is always eth5, simply because that's what the said file
>  >> says.
> 
>  > Not always. You are wrong here, I'm afraid:
> 
>  > Lets assume that eth0-eth3 are not initialized at boot time and
>  > your init scripts attempt to initialize eth4 ...
> 
> Then I get an entry for eth4 in the `ifconfig` output, with NO entries
> for `eth0` through `eth3`, exactly as expected.

Did you ever try ? I think no. I've got the problem a few times while
(re)configuring multi-ethernet machines.

ne2k-pci is the first module loaded then and it finds two interfaces.
As there is no interfaces registered at the moment, they are named eth0 and
eth1 (sic!)

The interface names from modules.conf mean nothing here, they are ignored.

I see tho ways to get the proper intyerface names:
1. Force loading all modules in the appropriate sequence (ne before
   ne2k-pci) either manually or via pre-install command
2. Renaming interfaces after they are initialized (yes, interface names can
   be changed, but it is ugly)

> Note that the `ifconfig` command refers to the interfaces by name, and
> it's the settings in modules.conf that decide what type of interface
> that name refers to. That mapping can't be changed by any interface
> configuration or initialisation command, and the names used are those
> as given.

ifconfig does not assign interface names. The kernel driver (module) does.
And the driver has no option passed (even I thing it is impossiblke to pass
any) to define new interface naming scheme.

>  > To avoid such problems one probably should add a lot of
>  > pre-install parameters in modules.conf.
> 
> What problems?

Described above.

Andrzej
-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry@mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk

Re: How does "alias ethX drivername" in modules.conf work?

[Riley Williams]

Hi Andre.

 >>>>>>  Q> alias eth0 ne
 >>>>>>  Q> options eth0 io=0x340
 >>>>>>  Q> alias eth1 ne
 >>>>>>  Q> options eth1 io=0x320
 >>>>>>  Q> alias eth2 ne
 >>>>>>  Q> options eth2 io=0x2c0
 >>>>>>  Q> alias eth3 ne2k-pci
 >>>>>>  Q> alias eth4 ne2k-pci
 >>>>>>  Q> alias eth5 tulip

 >>>> However, if the cards are controlled by different drivers, you
 >>>> can influence the order they are detected in by your choice of
 >>>> entries in modules.conf - in the example above, the ISA cards
 >>>> are always eth0, eth1 and eth2, the NE2k-pci cards are always
 >>>      ^^^^^^

 >>>> eth3 and eth4, and the tulip card is always eth5, simply because
 >>>> that's what the said file says.

 >>> Not always. You are wrong here, I'm afraid:

 >>> Lets assume that eth0-eth3 are not initialized at boot time and
 >>> your init scripts attempt to initialize eth4 ...

I gather that I misunderstood what you were saying above, so let me
clarify what I now understand by your comments:

 1. You are assuming a broken set of init scripts. Specifically,
    they load the individual modules manually by the name of the
    module, rather than stating that you wish to initialise a
    particular interface and letting kmod sort out the correct
    module.

    If this is your assumption, then you've created an artificial
    situation that by its very nature is broken and unreliable.

 2. Alternatively, you are saying that in your setup, the module
    referred to by the `alias eth0` line in modules.conf was not
    compiled as part of the kernel.

    If this is your claim, then you have created a deliberately
    broken setup.

 3. Alternatively, you are saying that in your setup, the module
    referred to by the `alias eth0` line in modules.conf is the
    wrong module for that particular interface.

    If this is your claim, then you have again produced a broken
    setup.

 4. Alternatively, in your setup, there are interfaces controlled
    by the same driver that are separated by interfaces controlled
    by one or more other drivers.

    If this is your claim, then you will get the scenario that you
    describe, but this is simply because they are separated, and
    is corrected by renumbering them so that all interfaces that
    are controlled by the same driver are contiguously numbered
    for all drivers.

As I see things, if you're referring to a situation covered by any of
the situations above, then my only interest is in advising you how to
correct the situation to get rid of the broken setup.

 >> Then I get an entry for eth4 in the `ifconfig` output, with NO
 >> entries for `eth0` through `eth3`, exactly as expected.

 > Did you ever try ?

Not with any of the broken scenarios described above, no.

 > I think no. I've got the problem a few times while
 > (re)configuring multi-ethernet machines.

 > ne2k-pci is the first module loaded...

If it is, then the setup falls into one of the scenarios above. The
CORRECT scenario (the only non-broken one) has ifconfig trying to
initialise the interfaces in the sequence eth0 - eth1 - ... - ethN
with kmod loading the appropriate driver for each one based on the
contents of the modules.conf file. ANY other scenario is broken by
design.

 > ...and it finds two interfaces. As there is no interfaces
 > registered at the moment, they are named eth0 and eth1 (sic!)

 > The interface names from modules.conf mean nothing here, they
 > are ignored.

Then the init scripts are broken as stated above.

 > I see tho ways to get the proper interface names:

 > 1. Force loading all modules in the appropriate sequence (ne before
 >    ne2k-pci) either manually or via pre-install command

 > 2. Renaming interfaces after they are initialized (yes,
 >    interface names can be changed, but it is ugly)

The first is not only the correct one, but also what just about every
system other than yours does by default.

 >> Note that the `ifconfig` command refers to the interfaces by
 >> name, and it's the settings in modules.conf that decide what
 >> type of interface that name refers to. That mapping can't be
 >> changed by any interface configuration or initialisation
 >> command, and the names used are those as given.

 > ifconfig does not assign interface names. The kernel driver
 > (module) does. And the driver has no option passed (even I thing
 > it is impossiblke to pass any) to define new interface naming
 > scheme.

Here's what is supposed to happen:

 1. ifconfig tries to initialise interface eth0.

 2. The kernel sees that interface eth0 doesn't exist as a module
    so asks the kmod driver to load it.

 3. The kmod driver refers to the modules.conf file to determine
    the true name for the eth0 interface. On my system, it sees
    the line `alias eth0 ne` telling it that eth0 is controlled by
    the module ne.

 4. The kmod driver checks whether the ne driver is loaded, and
    loads it if not.

 5. The kmod driver advises the kernel that the eth0 module has
    beel loaded at whatever address the ne driver was loaded at.

 6. The kernel then uses that module to refer to the eth0 driver.

Note that the kernel assigns interface names BASED ON WHAT IFCONFIG
DOES. If ifconfig tries to initialise eth1 before eth0 then the kernel
will get out of step with everything else, and correctly so. That's a
bug in the init scripts, not in the kernel.

 >>> To avoid such problems one probably should add a lot of
 >>> pre-install parameters in modules.conf.

 >> What problems?

 > Described above.

What KERNEL problems then? I don't see any yet.

Best wishes from Riley.

Re: How does "alias ethX drivername" in modules.conf work?

[Mark Atwood]

Riley Williams <rhw@MemAlpha.CX> writes:
> 
>  > Described above.
> 
> What KERNEL problems then? I don't see any yet.

I smell the stench of finger pointing. It's a pity that it stinks jsut
as bad in the open source world as it is I am "privileged" when closed
source shops, or (even worse) telco/network folks start playing
"blameball".

Userspace init scripts point the finger at kernel, saying "there is no
good and no well documented mapping method". Kernel points its finger
at userspace, saying "this is the way we do it" and "we cant guarantee
a perfect 100% mapping solution, so we're not even going to try for
90%" and "futz with your drivers and modules.conf and init scripts
till you get something that works".

Fingers back and forth, fingers pointing all around

and those of us with lots of different interfaces, and
those of us with several hot-plug interfaces

What happens to us?

We get the finger.

-- 
Mark Atwood   | I'm wearing black only until I find something darker.
mra@pobox.com | http://www.pobox.com/~mra

Re: How does "alias ethX drivername" in modules.conf work?

[Tim Jansen]

On Tuesday 07 August 2001 23:46, Mark Atwood wrote:
> Userspace init scripts point the finger at kernel, saying "there is no
> good and no well documented mapping method". Kernel points its finger
> at userspace, saying "this is the way we do it" and "we cant guarantee
> a perfect 100% mapping solution, so we're not even going to try for
> 90%" and "futz with your drivers and modules.conf and init scripts
> till you get something that works".

I'm working on one a possible solution, the Device Registry 
(www.tjansen.de/devreg). It solves this problem by assigning device ids to 
physical devices. This allows you to identify a physical device, even after 
you changed tge port.

Device ids can be used in two ways:
1. user space apps can use the device id to find the device's node in /dev
2. a user-space daemon can use the device ids to create stable symlinks to 
the /dev nodes (this is not possible to ethernet ids though)

bye...

Re: How does "alias ethX drivername" in modules.conf work?

[Josh Wyatt]

Tim Jansen wrote:
> 
> On Tuesday 07 August 2001 23:46, Mark Atwood wrote:
> > Userspace init scripts point the finger at kernel, saying "there is no
> > good and no well documented mapping method". Kernel points its finger
> > at userspace, saying "this is the way we do it" and "we cant guarantee
> > a perfect 100% mapping solution, so we're not even going to try for
> > 90%" and "futz with your drivers and modules.conf and init scripts
> > till you get something that works".
> 
> I'm working on one a possible solution, the Device Registry
> (www.tjansen.de/devreg). It solves this problem by assigning device ids to
> physical devices. This allows you to identify a physical device, even after
> you changed tge port.

Sounds interestingly like the solaris solution to the problem,
/etc/path_to_inst.
Thanks,
Josh

Re: How does "alias ethX drivername" in modules.conf work?

[Riley Williams]

Hi Mark.

 >>> Described above.

 >> What KERNEL problems then? I don't see any yet.

 > I smell the stench of finger pointing. It's a pity that it
 > stinks jsut as bad in the open source world as it is I am
 > "privileged" when closed source shops, or (even worse)
 > telco/network folks start playing "blameball".

I'm trying not to point any fingers anywhere, but I have to admit that
I'm finding it VERY difficult in this case. The basic problem that I
have is that the "way it's done" that I referred to in my posts so far
is the way that RedHat, Caldera, Debian, Mandrake, SUSE and Eridani
Linux all do it by default (I can't comment on SlackWare as I've never
been able to get it to install myself and don't know anybody who runs
it).

 > Userspace init scripts point the finger at kernel, saying "there
 > is no good and no well documented mapping method". Kernel points
 > its finger at userspace, saying "this is the way we do it" and
 > "we cant guarantee a perfect 100% mapping solution, so we're not
 > even going to try for 90%" and "futz with your drivers and
 > modules.conf and init scripts till you get something that
 > works".

I've certainly never stood in the position you call "Kernel" in that
description. Here's the situation as I see it, put in those sort of
terms, characters being InitScripts and Kernel respectively:

 1. InitScripts points at Kernel saying "there is no good and no
    well documented mapping method".

 2. Kernel replies "There is a good mapping method, which is to
    always map the ports starting with the lowest numbered one."

 3. InitScripts then tells Kernel "But I don't want to map the ports
    in ascending numerical order!"

So far, I've only seen the above scenario occur, and I have to admit
to having very little sympathy with it. However, I'm always open to
persuasion that the above is not the situation that is occurring.

 > Fingers back and forth, fingers pointing all around

 > and those of us with lots of different interfaces, and those of
 > us with several hot-plug interfaces

 > What happens to us?

 > We get the finger.

Not from me, you don't.

Let's deal with the various scenarios that I can see:

 1. Just one interface, either static or hotplug.

    By definition, there can be no problem here as the interface will
    always be eth0 when present, and missing when not.

 2. Multiple identical static interfaces.

    At the moment, you are required to initialise the interfaces in
    ascending order of their name in the modules.conf file.

    I've dealt with this situation on several occasions, and never
    found this to be a problem in any way.

 3. Multiple different static interfaces.

    At the moment, you are required to group these by the driver that
    controls them, simply because each driver will automatically map
    all interfaces that it supports when it is loaded. Likewise, you
    are required to initialise interfaces in ascending order of their
    name in the modules.conf file.

    I've dealt with this situation on several occasions, and never
    found this to be a problem in any way.

 4. Multiple hotplug interfaces.

    I have to admit to never having dealt with hotplug interfaces, but
    I understand some aspects of the interface are still being ironed
    out by the kernel developers. As a result, I would not be at all
    surprised to hear that problems still exist.

 5. Multiple static and hotplug interfaces.

    At the moment, you are required to group these by whether the
    interface is static or hotplug, configuring all static interfaces
    before any of the hotplug ones. This therefore reduces to being
    either case (2) or (3) followed by case (4), and should be dealt
    with accordingly.

As a result, the ONLY time I can see any problem occurring is when
there are multiple hotplug interfaces to deal with (case (4) above),
and this is acknowledged to be a case where some of the issues have
not yet been fully ironed out.

Can you agree with this analysis, or have I overlooked something?

Best wishes from Riley.

Re: How does "alias ethX drivername" in modules.conf work?

[Josh Wyatt]

Why not have a provision like the following:
1. For a given driver, assign ethX in [ascending|descending] (pick one)
order based on MAC addr.  At least this is a predictable order; it
should never change for a given driver.

2. If it's modular, you could make it even more flexible with options:
alias eth0 eepro100
alias eth1 ne2k-pci
alias eth2 eepro100
options eepro100 "bind_mac_order=eth0,eth2
bind_mac_list=00D0B760C299,00D0B760C3DC"

3. if it's modular and insmod'ed with no options, default to a combo of
the current behavior and #1, above.

Of course, you'd have to rely on the module maintainers to follow the
convention.

Also, I can see a potential dependency manifested in a scenario like
this:
1. add eth0, eth1, eth2 as above
2. un-hot-plug eth0.  now hotplug another interface, not used by the
previous driver
3. eepro100 driver is still bound to eth0
4. should the new device get eth3?  or eth0?  
5. Is this a textbook problem outside of PCMCIA?

Dumb? Klutzy? thoughts?

Thanks,
Josh

Re: How does "alias ethX drivername" in modules.conf work?

[Riley Williams]

Hi Josh.

 > Why not have a provision like the following:

 > 1. For a given driver, assign ethX in [ascending|descending]
 >    (pick one) order based on MAC addr. At least this is a
 >    predictable order; it should never change for a given driver.

Alan Cox will correct me if I'm wrong, but memory says that he pointed
out a while back some problem with this idea. I've cc'd this to him
for comments.

 > 2. If it's modular, you could make it even more flexible with options:

 > alias eth0 eepro100
 > alias eth1 ne2k-pci
 > alias eth2 eepro100
 > options eepro100 "bind_mac_order=eth0,eth2 \
 > bind_mac_list=00D0B760C299,00D0B760C3DC"

I would suspect that all that would be needed here would be for each
driver to only detect one interface each time it's called, so you
would get something like the following instead:

	alias eth0 eepro100
	options eth0 mac=00:D0:B7:60:C2:99
	alias eth1 ne2k-pci
	alias eth2 eepro100
	options eth2 mac=00:D0:B7:60:C3:DC

Incidentally, this follows the current modules.conf syntax rules, and
(in this particular case) would be likely to be much simpler than your
proposed change. Specifying the options on the interface rather than
the driver is the ONLY way to specify different parameters for
different interfaces in a flexible manner.

 > 3. If it's modular and insmod'ed with no options, default to a
 >    combo of the current behavior and #1, above.

 > Of course, you'd have to rely on the module maintainers to
 > follow the convention.

With the revised scenario, they already follow the convention because
that is the current convention.

 > Also, I can see a potential dependency manifested in a scenario
 > like this:

Your scenario has already been considered.

 > 1. add eth0, eth1, eth2 as above
 > 2. un-hot-plug eth0.

Two points here:

 1. The fact that you can un-hot-plug eth0 states that you can
    also un-hot-plug eth1 and eth2. Any interfaces that can't be
    hot-plugged are currently required to be set up before any of
    the hot-pluggable ones.

 2. The hotplug interface signals to the driver that this has
    happenned, so the driver de-registers eth0 by doing the
    equivalent of `ifconfig eth0 down ; rmmod eth0` internally.

We continue...

 > 3. now hotplug another interface, not used by the previous driver
 > 4. eepro100 driver is still bound to eth0

No it isn't - see comments above.

 > 5. should the new device get eth3?  or eth0?

As eth0 was auto-deregistered at point (2), it's actually irrelevant
which it gets.

 > 6. Is this a textbook problem outside of PCMCIA?

It's one that has already been dealt with as part of the PCMCIA
specification, and is thus already supported by the Linux PCMCIA
interface.

I understand we can blame/credit Microsoft with the fact that this
scenario was considered as part of the PCMCIA specification.

 > Dumb? Klutzy? thoughts?

Neither dumb nor a problem.

Best wishes from Riley.

Re: How does "alias ethX drivername" in modules.conf work?

[Alan Cox]

>  > Why not have a provision like the following:
> 
>  > 1. For a given driver, assign ethX in [ascending|descending]
>  >    (pick one) order based on MAC addr. At least this is a
>  >    predictable order; it should never change for a given driver.
> 
> Alan Cox will correct me if I'm wrong, but memory says that he pointed
> out a while back some problem with this idea. I've cc'd this to him
> for comments.

Correct. MAC addresses are defined per machine not per card. That they tend
to be per card is on a PC isnt always true elsewhere. For example many sparc
boxes have one mac per machine.

Its still a valuable way of naming devices. 

Re: How does "alias ethX drivername" in modules.conf work?

[Mark Atwood]

Riley Williams <rhw@MemAlpha.CX> writes:
> 
> I've certainly never stood in the position you call "Kernel" in that
> description. Here's the situation as I see it, put in those sort of
> terms, characters being InitScripts and Kernel respectively:
> 
>  1. InitScripts points at Kernel saying "there is no good and no
>     well documented mapping method".
> 
>  2. Kernel replies "There is a good mapping method, which is to
>     always map the ports starting with the lowest numbered one."

Well, there is that present mapping method, but I hesitate to call it
"good".


Plus, we are unable to satisfactorily define "lowest numbered one".


If I build a system with several identical (other than MAC) FooCorp
PCI ethernics, they will number up in order of ascending MAC address.

I take the same system, replace the FooCorp cards with BarInc NICs, they
will number up in reverse MAC address.

Replace them instead with Baz Systems NICs, and I get them in bus scan
order (at which point I'm dependent on the firmware version of my PCI
bridge too!).

And if I elect to use Frob Networking NICs, I instead get them in the
*random* order that their oncard processors won the race to power up.


Gods and demons help me if I try putting several of all four brands in
one box, or the firmware on my NICs or in my PCI bridges changes!

> 
>  3. InitScripts then tells Kernel "But I don't want to map the ports
>     in ascending numerical order!"

The phrase "ascending numerical order" becomes, depending on if you
have a complex (lots of different kinds of interfaces) or dynamic
(ferex, with PCMCIA, CompactPCI, USB, and Firewire ethernet
interfaces), either useless or undefined.


-- 
Mark Atwood   | I'm wearing black only until I find something darker.
mra@pobox.com | http://www.pobox.com/~mra

Re: How does "alias ethX drivername" in modules.conf work?

[Riley Williams]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2891 bytes --]

Hi Mark.

 >> I've certainly never stood in the position you call "Kernel" in
 >> that description. Here's the situation as I see it, put in those
 >> sort of terms, characters being InitScripts and Kernel
 >> respectively:
 >>
 >>  1. InitScripts points at Kernel saying "there is no good and no
 >>     well documented mapping method".
 >>
 >>  2. Kernel replies "There is a good mapping method, which is to
 >>     always map the ports starting with the lowest numbered one."

 > Well, there is that present mapping method, but I hesitate to
 > call it "good".
 >
 > Plus, we are unable to satisfactorily define "lowest numbered
 > one".

Why? When is eth0 higher numbered than eth1 for example?

 > If I build a system with several identical (other than MAC)
 > FooCorp PCI ethernics, they will number up in order of ascending
 > MAC address.
 >
 > I take the same system, replace the FooCorp cards with BarInc
 > NICs, they will number up in reverse MAC address.
 >
 > Replace them instead with Baz Systems NICs, and I get them in
 > bus scan order (at which point I'm dependent on the firmware
 > version of my PCI bridge too!).
 >
 > And if I elect to use Frob Networking NICs, I instead get them
 > in the *random* order that their oncard processors won the race
 > to power up.
 >
 > Gods and demons help me if I try putting several of all four
 > brands in one box, or the firmware on my NICs or in my PCI
 > bridges changes!

I dealt with this problem in a previous email, but will repeat it for
your benefit. The ONLY provisos I will use are the following two:

 1. All ethernet interfaces in your machine have distinct MAC's.

 2. If the firmware in your NIC's changes, the MAC's do not.

Providing both of these are met, the enclosed BASH SHELL SCRIPT
implements the `ifconfig` command with the port name replaced by its
MAC address.

With this change, it doesn't actually matter what port name a
particular interface is given, because ALL of the other network config
tools refer to the interface by its assigned IP address, not its port
name. As a result, if its port name changes between boots, the routing
automatically changes with it.

 >>  3. InitScripts then tells Kernel "But I don't want to map the
 >>    ports in ascending numerical order!"

 > The phrase "ascending numerical order" becomes, depending on if
 > you have a complex (lots of different kinds of interfaces) or
 > dynamic (ferex, with PCMCIA, CompactPCI, USB, and Firewire
 > ethernet interfaces), either useless or undefined.

I disagree: The phrase "ascending numerical order" has a FIXED
meaning, namely that eth0 comes before eth1 which comes before eth2.

You appear to have assumed that I was referring to ascending MAC
address, and such an assumption makes nonsense of most of what I said,
but if you use the meaning I used, you'll see it makes perfect sense
throughout.

Best wishes from Riley.

[-- Attachment #2: /usr/local/sbin/ifmap --]
[-- Type: TEXT/PLAIN, Size: 1504 bytes --]

#!/bin/bash

###############################################################################
#
# This script provides a version of the `ifconfig` command that expects to
# see the ethernet address associated with a particular port, and performs
# the stated actions on whichever ethernet interface has the specified
# ethernet address. All actions associated with the `ifconfig` command are
# supported, and the only change in syntax is that the port name of "eth?"
# is replaced by the associated ethernet address.
#
# If no ethernet interface is found with the specified ethernet address, 
# this script uses a return value of 1, otherwise it uses a return value
# of 0.
#
###############################################################################

function assign() {
    local HW="$1" OK=Y
    declare -i N=0

    shift 1
    while [ $OK = Y ]; do
	if ! port eth$N ; then
	    if ifconfig eth$N up 2> /dev/null ; then
		if [ "`hwaddr eth$N`" != "${HW}" ]; then
		    ifconfig eth$N down
		else
		    ifconfig eth$N "$@"
		    OK=$?
		fi
	    else
		OK=0
	    fi
	fi
	N=$N+1
    done
    return $OK
}

function hwaddr() {
    ifconfig "$1" | grep "^$1" | tr ' ' '\n' | grep '[0-9A-F]:[0-9A-F]'
}

function port() {
    ifconfig | grep ^eth | fgrep "$1" > /dev/null
}

if [ $# -gt 0 ]; then
    if assign "$@" ; then
	echo No ethernet interface with address "$1" found. >&2
	exit 1
    else
	exit 0
    fi
else
    ifconfig
    exit 0
fi

Re: How does "alias ethX drivername" in modules.conf work?

[Andrzej Krzysztofowicz]

"Riley Williams wrote:"
>  > If I build a system with several identical (other than MAC)
>  > FooCorp PCI ethernics, they will number up in order of ascending
>  > MAC address.
>  >
>  > I take the same system, replace the FooCorp cards with BarInc
>  > NICs, they will number up in reverse MAC address.
>  >
>  > Replace them instead with Baz Systems NICs, and I get them in
>  > bus scan order (at which point I'm dependent on the firmware
>  > version of my PCI bridge too!).
>  >
>  > And if I elect to use Frob Networking NICs, I instead get them
>  > in the *random* order that their oncard processors won the race
>  > to power up.
>  >
>  > Gods and demons help me if I try putting several of all four
>  > brands in one box, or the firmware on my NICs or in my PCI
>  > bridges changes!
> 
> I dealt with this problem in a previous email, but will repeat it for
> your benefit. The ONLY provisos I will use are the following two:
> 
>  1. All ethernet interfaces in your machine have distinct MAC's.
> 
>  2. If the firmware in your NIC's changes, the MAC's do not.
> 
> Providing both of these are met, the enclosed BASH SHELL SCRIPT
> implements the `ifconfig` command with the port name replaced by its
> MAC address.

1. NFS-root needs to have RARP/NFS servers on eth0.
   How can you deal with it if you have two boards supported by a single
   driver and, unfortunately, the one you need is detected as eth1 ?
   Assume that you cannot switch them as they use different media type...

> With this change, it doesn't actually matter what port name a
> particular interface is given, because ALL of the other network config
> tools refer to the interface by its assigned IP address, not its port
> name. As a result, if its port name changes between boots, the routing
> automatically changes with it.

2. ipfwadm / ipchains / iptables may use interface names,
3. dhcpd may need interface names to be provided,
4. you may want to pass an interface name argument to tcpdump...

In 2.2+ you can deal with 2.-4. changing interface names using ip from
iproute2. But I doubt whether ifconfig based scripts would work properly
then. And problem 1. is still valid ...

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry@mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk

Re: How does "alias ethX drivername" in modules.conf work?

[Eric W. Biederman]

Andrzej Krzysztofowicz <ankry@pg.gda.pl> writes:

> 1. NFS-root needs to have RARP/NFS servers on eth0.
>    How can you deal with it if you have two boards supported by a single
>    driver and, unfortunately, the one you need is detected as eth1 ?
>    Assume that you cannot switch them as they use different media type...

Hmm.  Then my system that does DHCP/NFS root with 2.4.7 and comes up
on eth2 is doesn't work?  Hmm it looks like it works to me.

Eric

Re: How does "alias ethX drivername" in modules.conf work?

[Andrzej Krzysztofowicz]

> 
> Andrzej Krzysztofowicz <ankry@pg.gda.pl> writes:
> 
> > 1. NFS-root needs to have RARP/NFS servers on eth0.
> >    How can you deal with it if you have two boards supported by a single
> >    driver and, unfortunately, the one you need is detected as eth1 ?
> >    Assume that you cannot switch them as they use different media type...
> 
> Hmm.  Then my system that does DHCP/NFS root with 2.4.7 and comes up
> on eth2 is doesn't work?  Hmm it looks like it works to me.

Then the documentation I've read must be outdated.
Sorry.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry@mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk

Re: How does "alias ethX drivername" in modules.conf work?

[Riley Williams]

Hi Eric.

 >> 1. NFS-root needs to have RARP/NFS servers on eth0.

 >> How can you deal with it if you have two boards supported by a
 >> single driver and, unfortunately, the one you need is detected
 >> as eth1 ? Assume that you cannot switch them as they use
 >> different media type...

 > Hmm. Then my system that does DHCP/NFS root with 2.4.7 and comes
 > up on eth2 is doesn't work?  Hmm it looks like it works to me.

I have no personal experience of NFS-Root but the documentation I've
seen all implied that it did the RARP broadcast in parallel on all
configured NIC's and used the one that replied from there on. I'm glad
to hear that my reading of the documentation was correct.

Best wishes from Riley.

Re: How does "alias ethX drivername" in modules.conf work?

[Riley Williams]

Hi Andrzej.

 >>> If I build a system with several identical (other than MAC)
 >>> FooCorp PCI ethernics, they will number up in order of
 >>> ascending MAC address.
 >>>
 >>> I take the same system, replace the FooCorp cards with BarInc
 >>> NICs, they will number up in reverse MAC address.
 >>>
 >>> Replace them instead with Baz Systems NICs, and I get them in
 >>> bus scan order (at which point I'm dependent on the firmware
 >>> version of my PCI bridge too!).
 >>>
 >>> And if I elect to use Frob Networking NICs, I instead get them
 >>> in the *random* order that their oncard processors won the race
 >>> to power up.
 >>>
 >>> Gods and demons help me if I try putting several of all four
 >>> brands in one box, or the firmware on my NICs or in my PCI
 >>> bridges changes!

 >> I dealt with this problem in a previous email, but will repeat it
 >> for your benefit. The ONLY provisos I will use are the following
 >> two:
 >>
 >>  1. All ethernet interfaces in your machine have distinct MAC's.
 >>
 >>  2. If the firmware in your NIC's changes, the MAC's do not.
 >>
 >> Providing both of these are met, the enclosed BASH SHELL SCRIPT
 >> implements the `ifconfig` command with the port name replaced by
 >> its MAC address.

 > 1. NFS-root needs to have RARP/NFS servers on eth0.

I have to admit that I've never actually used NFS root, although I
have read documents on it. I also have to say that my understanding
was that it broadcast RARP packets on ALL configured network ports,
and used the lowest numbered one for the rest of the boot process. If
this isn't the case, then the documentation needs to be changed to
reflect what it actually does - or, better still, the behaviour needs
to be changed to match the documentation, as the documented behaviour
would kill this problem completely.

 > How can you deal with it if you have two boards supported by a
 > single driver and, unfortunately, the one you need is detected
 > as eth1 ? Assume that you cannot switch them as they use
 > different media type...

Assuming your claim is correct, then the behaviour needs to be changed
to comform to the documeted behaviour, so this should be reported as a
bug - IMHO, that is.

 >> With this change, it doesn't actually matter what port name a
 >> particular interface is given, because ALL of the other network
 >> config tools refer to the interface by its assigned IP address,
 >> not its port name. As a result, if its port name changes between
 >> boots, the routing automatically changes with it.

 > 2. ipfwadm / ipchains / iptables may use interface names,

I've yet to use iptables, so can't comment on that. With both ipfwadm
and ipchains, the ONLY ports I've ever had reason to explicitly name
have always been either ppp+ to refer to the PPP link across the
modem, or sl0 to refer to the AX.25 link to my ham radio stuff. As a
result, I've never actually experienced a situation that would be
affected by this.

However, it's not hard to write code to translate. How about hw2eth
which is a BASH script to convert from a stated MAC address to the
port that MAC is mapped to:

 Q> ifconfig | grep ^eth | fgrep "HWaddr $1" | cut -d ' ' -f 1

How about ip2eth which is a BASH script to convert from the local IP
address of the port the interface in question maps to to its port
name:

 Q> ifconfig | grep -B1 "inet addr:$1" | grep ^eth | cut -d ' ' -f 1

The other option, route2eth (a program to convert a particular remote
IP address to the port name of the interface we would use to connect
to it) involves analysing the output of `route -n` so would be rather
better suited to a C (or other) compiled program. However, even this
shouldn't be that hard for a competent programmer to produce.

 > 3. dhcpd may need interface names to be provided,

I have to admit that I've never used dhcpd, so am somewhat
disadvantaged here. However, I would imagine that the scripts above
would provide the necessary translations.

 > 4. you may want to pass an interface name argument to tcpdump.

Whenever I use tcpdump on a system with multiple NIC's, I always have
to use `ifconfig` to remember which interface attaches to which
network, and then use the interface determined from that. I would
assume that others would tend to do the same, and in this case, this
problem case vanishes.

Even if this wasn't the case, the scripts above should help to
minimise the problems.

 > In 2.2+ you can deal with 2.-4. changing interface names using
 > ip from iproute2. But I doubt whether ifconfig based scripts
 > would work properly then.

You shouldn't need to fudge the issue like that anyway, and if you do,
then the various tools need to be redesigned to provide simple ways
round the problem.

 > And problem 1. is still valid ...

So is the solution above.

Best wishes from Riley.

Re: How does "alias ethX drivername" in modules.conf work?

[Mark Atwood]

Riley Williams <rhw@MemAlpha.CX> writes:
> 
>     At the moment, you are required to group these by whether the
>     interface is static or hotplug, configuring all static interfaces
>     before any of the hotplug ones. This therefore reduces to being
>     either case (2) or (3) followed by case (4), and should be dealt
>     with accordingly.
> 
> As a result, the ONLY time I can see any problem occurring is when
> there are multiple hotplug interfaces to deal with (case (4) above),
> and this is acknowledged to be a case where some of the issues have
> not yet been fully ironed out.
> 
> Can you agree with this analysis, or have I overlooked something?

That is, yes indeed, pretty much the proper analysis, and my
situtation. My case can be summarized as one static interface,
followed by two (and if we can get the firewire stuff working, soon
potentially to be more) dynamic interfaces.


-- 
Mark Atwood   | I'm wearing black only until I find something darker.
mra@pobox.com | http://www.pobox.com/~mra

Re: How does "alias ethX drivername" in modules.conf work?

[Riley Williams]

Hi Mark.

 >>	At the moment, you are required to group these by whether the
 >>     interface is static or hotplug, configuring all static interfaces
 >>     before any of the hotplug ones. This therefore reduces to being
 >>     either case (2) or (3) followed by case (4), and should be dealt
 >>     with accordingly.
 >>
 >> As a result, the ONLY time I can see any problem occurring is when
 >> there are multiple hotplug interfaces to deal with (case (4) above),
 >> and this is acknowledged to be a case where some of the issues have
 >> not yet been fully ironed out.
 >>
 >> Can you agree with this analysis, or have I overlooked something?

 > That is, yes indeed, pretty much the proper analysis, and my
 > situtation. My case can be summarized as one static interface,
 > followed by two (and if we can get the firewire stuff working,
 > soon potentially to be more) dynamic interfaces.

As long as the static interface is configured as eth0 before any of
the dynamic interfaces are looked at, it will remain fixed, and gets
taken out of the equation as a result.

As I understand it, the PCMCIA interface does the equivalent of...

	ifconfig eth1 down ; rmmod eth1

...when the interface on eth1 is unplugged, so the unplugging
shouldn't be a problem. However, I've no idea what it does on plugging
in a new interface, other than that is somehow signals the fact to the
kernel.

I can't comment on firewall as I know zilch about it, sorry.

Best wishes from Riley.

Re: How does "alias ethX drivername" in modules.conf work?

[Mark Atwood]

(apologies for splitting my reply into multiple pieces, but each part
 covers different territory).

Riley Williams <rhw@MemAlpha.CX> writes:
> 
>  2. Multiple identical static interfaces.
> 
>     At the moment, you are required to initialise the interfaces in
>     ascending order of their name in the modules.conf file.
> 
>     I've dealt with this situation on several occasions, and never
>     found this to be a problem in any way.

Have you ever assembled a distribution that's going to be imaged into
several thousands to several tens of thousands of hardware boxes, with
evolving-into-the-future changes in hardware version and changes in
component suppliers?

If Linux really wants to break into the appliance market, this is
going to be a bigger and bigger issue.

-- 
Mark Atwood   | I'm wearing black only until I find something darker.
mra@pobox.com | http://www.pobox.com/~mra

Re: How does "alias ethX drivername" in modules.conf work?

[Riley Williams]

Hi Mark.

 > (apologies for splitting my reply into multiple pieces, but each
 > part covers different territory).

 >>  2. Multiple identical static interfaces.
 >>
 >>     At the moment, you are required to initialise the interfaces in
 >>     ascending order of their name in the modules.conf file.
 >>
 >>     I've dealt with this situation on several occasions, and never
 >>     found this to be a problem in any way.

 > Have you ever assembled a distribution that's going to be imaged
 > into several thousands to several tens of thousands of hardware
 > boxes, with evolving-into-the-future changes in hardware version
 > and changes in component suppliers?

I haven't personally, no, but RedHat, Caldera, SUSE, Debian and
Eridani all have, and (curiously enough) they all use the same basic
solution, although implemented in different ways. This is also the
solution implemented by the ifmap script I attached to my previous
email.

 > If Linux really wants to break into the appliance market, this
 > is going to be a bigger and bigger issue.

Agreed, but then, it appears to be an issue that has largely been
solved. The only part that may still need attention (I'm not up to
date on it, so can't say for sure) is the hotplug stuff.

Best wishes from Riley.

Re: How does "alias ethX drivername" in modules.conf work?

[Andrzej Krzysztofowicz]

"Riley Williams wrote:"

>  1. InitScripts points at Kernel ...
>  2. Kernel replies ...
>  3. InitScripts then tells Kernel ...

I believe this discussion leads to constructive conlusions.
Even if that are 2.5+ conclusions.

> So far, I've only seen the above scenario occur, and I have to admit
> to having very little sympathy with it. However, I'm always open to
> persuasion that the above is not the situation that is occurring.

[...]

> Let's deal with the various scenarios that I can see:
> 
>  1. Just one interface, either static or hotplug.
Nothing interesting.

>  2. Multiple identical static interfaces.
Nothing interesting.

>  3. Multiple different static interfaces.
I see some subcases here:

3a. All interfaces are initialized

3b. Not all interfaces are initialized 
    [ "interface physicaly exist" != "interface is connected/configured"

3c. Interfaces supported by single driver are identical

3d. Interfaces supported by single driver are significantly different

I thing one met some common problems with the hotplug case here in the above
subcases.

>     At the moment, you are required to group these by the driver that
>     controls them, simply because each driver will automatically map
>     all interfaces that it supports when it is loaded. Likewise, you
>     are required to initialise interfaces in ascending order of their
>     name in the modules.conf file.
> 
>  4. Multiple hotplug interfaces.

I thing this case and 3. case should be solved both: for the modular drivers
case and for the built-in drivers case.

>     I have to admit to never having dealt with hotplug interfaces, but
>     I understand some aspects of the interface are still being ironed
>     out by the kernel developers. As a result, I would not be at all
>     surprised to hear that problems still exist.
> 
>  5. Multiple static and hotplug interfaces.
> 
>     At the moment, you are required to group these by whether the
>     interface is static or hotplug, configuring all static interfaces
>     before any of the hotplug ones. This therefore reduces to being
>     either case (2) or (3) followed by case (4), and should be dealt
>     with accordingly.

Consider complex situation: you have two drivers, each of them supporting
static and built in and hotplug interfaces.
Yes, this is a theoretical problem, but solving it would probably also solve
all (or almost all) of the above cases.

I like the idea of assigning names by MAC addresses. It IMO should solve
all problems as:
- if more then one interface has the same MAC address, they are probably
  identical, and you can switch them in hardware (cabling). Or am I
  wrong here?
- If you want to change the MAC address you do it *AFTER* the interface
  is initialized (driver is loaded, interface name is assigned). Or am 
  I also wrong here?

This seem to be a good idea if there's also support for "ether=" like
global kernel parameter working for build-in drivers.

> As a result, the ONLY time I can see any problem occurring is when
> there are multiple hotplug interfaces to deal with (case (4) above),
> and this is acknowledged to be a case where some of the issues have
> not yet been fully ironed out.
> 
> Can you agree with this analysis, or have I overlooked something?

Andrzej
-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry@mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk

Re: How does "alias ethX drivername" in modules.conf work?

[Riley Williams]

Hi again Andrzej.

 >>  1. InitScripts points at Kernel ...
 >>  2. Kernel replies ...
 >>  3. InitScripts then tells Kernel ...

 > I believe this discussion leads to constructive conlusions. Even
 > if that are 2.5+ conclusions.

So do I.

 >> So far, I've only seen the above scenario occur, and I have to
 >> admit to having very little sympathy with it. However, I'm
 >> always open to persuasion that the above is not the situation
 >> that is occurring.

 >> Let's deal with the various scenarios that I can see:
 >>
 >>  1. Just one interface, either static or hotplug.

 > Nothing interesting.

 >>  2. Multiple identical static interfaces.

 > Nothing interesting.

Agreed.

 >>  3. Multiple different static interfaces.

 > I see some subcases here:

 > 3a. All interfaces are initialized

This is the assumption used by all of the standard distributions (with
the possible exception of Slackware, but I'd be surprised if they
differ here).

 > 3b. Not all interfaces are initialized
 >     "interface physicaly exist" != "interface is connected/configured"

This is definitely a problem case, as it leads to all sorts of race
scenarios. Even Microsoft don't support this case with their operating
systems.

 > 3c. Interfaces supported by single driver are identical
 >
 > 3d. Interfaces supported by single driver are significantly different

With static interfaces, the difference between these two subcases is
in theory irrelevant.

 > I thing one met some common problems with the hotplug case here
 > in the above subcases.

Can I point out that this section specifically refers to STATIC (ie,
non-hotplug) interfaces. This comment is therefore irrelevant here.

 >>     At the moment, you are required to group these by the driver that
 >>     controls them, simply because each driver will automatically map
 >>     all interfaces that it supports when it is loaded. Likewise, you
 >>     are required to initialise interfaces in ascending order of their
 >>     name in the modules.conf file.

 >>  4. Multiple hotplug interfaces.

 > I thing this case and 3. case should be solved both: for the
 > modular drivers case and for the built-in drivers case.

Case (3) is already solved. Case (4) is the only one that needs
solving, and that's still under development with various other
problems to be solved as well.

 >>     I have to admit to never having dealt with hotplug interfaces, but
 >>     I understand some aspects of the interface are still being ironed
 >>     out by the kernel developers. As a result, I would not be at all
 >>     surprised to hear that problems still exist.
 >>
 >>  5. Multiple static and hotplug interfaces.
 >>
 >>     At the moment, you are required to group these by whether the
 >>     interface is static or hotplug, configuring all static interfaces
 >>     before any of the hotplug ones. This therefore reduces to being
 >>     either case (2) or (3) followed by case (4), and should be dealt
 >>     with accordingly.

 > Consider complex situation: you have two drivers, each of them
 > supporting static and built in and hotplug interfaces. Yes, this
 > is a theoretical problem, but solving it would probably also
 > solve all (or almost all) of the above cases.

All drivers already support both static (which is built-in) and
hotplug interfaces, so that gains us nothing. All that changes in the
hotplug case is that the hotplug bus controller signals the kernel to
say either...

 1. "The device that was in my slot N has been unplugged", in which
    case the kernel unmaps the driver for that device, or

 2. "A new device has been plugged into my slot N", in which case the
    kernel works out what sort of device it is, then waits for some
    sort of configuration information.

As a result, most of the problems I've seen mentioned just can't
occur.

 > I like the idea of assigning names by MAC addresses. It IMO
 > should solve all problems as:

 > - if more then one interface has the same MAC address, they are
 >   probably identical, and you can switch them in hardware
 >   (cabling). Or am I wrong here?

According to Alan Cox, it's only the ix86 architecture where the MAC
is per interface; on all other architectures, it's one MAC per system
that is shared by all the ethernet interfaces. As a result, there is
no guarantee that they are identical, or even similar.

 > - If you want to change the MAC address you do it *AFTER* the
 >   interface is initialized (driver is loaded, interface name is
 >   assigned). Or am I also wrong here?

I have no idea, and would not assume either way.

 > This seem to be a good idea if there's also support for "ether="
 > like global kernel parameter working for build-in drivers.

I have to agree that this may be a good idea for the ix86
architecture, but not for other architectures because of that
limitation. However, this may be something that has to be solved on a
per-architecture basis.

 >> As a result, the ONLY time I can see any problem occurring is when
 >> there are multiple hotplug interfaces to deal with (case (4) above),
 >> and this is acknowledged to be a case where some of the issues have
 >> not yet been fully ironed out.
 >>
 >> Can you agree with this analysis, or have I overlooked something?

Best wishes from Riley.

Re: How does "alias ethX drivername" in modules.conf work?

[Alan Cox]

One point to remind people of here. You can runtime rename interfaces.
Almost all the needed kernel infrastructure is there already.

Alan

Re: How does "alias ethX drivername" in modules.conf work?

[Horst von Brand]

Riley Williams <rhw@MemAlpha.CX> said:

[...]

> According to Alan Cox, it's only the ix86 architecture where the MAC
> is per interface; on all other architectures, it's one MAC per system
> that is shared by all the ethernet interfaces. As a result, there is
> no guarantee that they are identical, or even similar.

On Sun all NICs of a machine by default share the same MAC (and you can
change them individually at will, BTW). Other machines I've come across
aren't this way. But there are several NICs around (even seen them on PCs,
don't remember which ones, sorry) where you can change the MAC at will, and
the change sticks IIRC.

If you look at how Ethernet works, it is clear that the MAC has to be
unique on its network segment only, making it globally unique is simple,
but way overkill.

Re: How does "alias ethX drivername" in modules.conf work?

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>Hi Mark.
>
> >>> Described above.
>
> >> What KERNEL problems then? I don't see any yet.
>
> > I smell the stench of finger pointing. It's a pity that it
> > stinks jsut as bad in the open source world as it is I am
> > "privileged" when closed source shops, or (even worse)
> > telco/network folks start playing "blameball".
>
>I'm trying not to point any fingers anywhere, but I have to admit that
>I'm finding it VERY difficult in this case. The basic problem that I
>have is that the "way it's done" that I referred to in my posts so far
>is the way that RedHat, Caldera, Debian, Mandrake, SUSE and Eridani
>Linux all do it by default (I can't comment on SlackWare as I've never
>been able to get it to install myself and don't know anybody who runs
>it).


Takes about 5 minutes to setup a Slackware install and about 3 minutes
after floppy boot to install it.  Init scripts are not SysV
(wonderful!), nor do they contain some of the Redhat silliness ( ">
/etc/mtab" is stupid, dies everytime something eariler in the kernel
gets upset).  But the init scripts do not handle multiple interfaces
out of the box either.

My answer has always been a combination of built-in interfaces (for
the default routes), modules, and either all unique cards or all the
same.  It's custom and works fine until the hardware is changed...  A
general solution would be appreciated.

Re: How does "alias ethX drivername" in modules.conf work?

[Paul Gortmaker]

Riley Williams wrote:

> One of my systems has SIX ethernet cards, these being three ISA and
> two PCI NE2000 clones and a DEC Tulip. Here's the relevant section of
> modules.conf on the system in question:
> 
>  Q> alias eth0 ne
>  Q> options eth0 io=0x340
>  Q> alias eth1 ne
>  Q> options eth1 io=0x320
>  Q> alias eth2 ne
>  Q> options eth2 io=0x2c0
>  Q> alias eth3 ne2k-pci
>  Q> alias eth4 ne2k-pci
>  Q> alias eth5 tulip

You have six drivers loaded, when you only need three (i.e.
io=0x340,0x320,0x2c0 for ne options etc. etc).  So you end
up wasting some memory, and a worse icache behaviour as well.
(the latter is probably a non-issue if you are happy with ISA)

Paul.

Re: How does "alias ethX drivername" in modules.conf work?

[Riley Williams]

Hi Paul.

 >> One of my systems has SIX ethernet cards, these being three ISA
 >> and two PCI NE2000 clones and a DEC Tulip. Here's the relevant
 >> section of modules.conf on the system in question:
 >>
 >>  Q> alias eth0 ne
 >>  Q> options eth0 io=0x340
 >>  Q> alias eth1 ne
 >>  Q> options eth1 io=0x320
 >>  Q> alias eth2 ne
 >>  Q> options eth2 io=0x2c0
 >>  Q> alias eth3 ne2k-pci
 >>  Q> alias eth4 ne2k-pci
 >>  Q> alias eth5 tulip

 > You have six drivers loaded, when you only need three (i.e.
 > io=0x340,0x320,0x2c0 for ne options etc. etc). So you end up
 > wasting some memory, and a worse icache behaviour as well.

Are you sure of this? My understanding (both from reading the code and
from what others I respect have said) is that it is impossible to load
any given module more than once, so the above will result in one copy
each of the ne, ne2k-pci and tulip drivers being loaded.

 > (the latter is probably a non-issue if you are happy with ISA)

It's not so much a case of being "happy with ISA" as of needing six
interfaces on the same box, and it only has the three PCI slots...

Best wishes from Riley.

Re: How does "alias ethX drivername" in modules.conf work?

[Paul Gortmaker]

Riley Williams wrote:

> 
>  > You have six drivers loaded, when you only need three (i.e.
>  > io=0x340,0x320,0x2c0 for ne options etc. etc). So you end up
>  > wasting some memory, and a worse icache behaviour as well.
> 
> Are you sure of this? My understanding (both from reading the code and
> from what others I respect have said) is that it is impossible to load
> any given module more than once, so the above will result in one copy
> each of the ne, ne2k-pci and tulip drivers being loaded.

Here is an example of what I was talking about:

# insmod wd -o wd0 io=0x280 irq=10
# insmod wd -o wd1 io=0x680 irq=3
# insmod wd -o wd2 io=0xa80 irq=4
# insmod wd -o wd3 io=0xe80 irq=9
# cat /proc/modules
wd3                2            0
wd2                2            0
wd1                2            0
wd0                2            0
8390               2    [wd3 wd2 wd1 wd0]      0
# rmmod wd3 wd2 wd1 wd0
#
# insmod wd io=0x280,0x680,0xa80,0xe80 irq=10,3,4,9
# cat /proc/modules
wd                 2		0
8390               2	[wd]	0
#

The 1st way (4 copies of the driver present) will work, but is not
as efficient as the 2nd way (one copy present).

[Don't look too hard at the I/O addresses or you will realize there was 
only one card in this particular machine anyway...]

Paul.

How to tell how much to expect from a fd

[Mark Atwood]

Does there exist a fcntl or some other way to tell how much data is
"ready to be read" from a fd?

I'm doing this thing where I make the fd non-blocking, select on it,
and then read on it into a buffer that I am pregrowing with realloc.

When the high water mark is up to the top of the buffer, I realloc the
buffer to make it bigger.  At present, I'm just adding a constant
value to the buffer size each time I need to do this, but if there was
a way to easily tell how much was "ready to be read" from the fd.

It's not necessary to be exact. If more becomes available between the
time I do this wanted magic and do the read, read's 3rd parameter will
keep me safe, and if it's too low, like if a dup of the fd already
snarfed the data, also no big deal, I'm non-blocking and check the
return value.

So, is this "nice to have" available?


-- 
Mark Atwood   | Well done is better than well said.
mra@pobox.com | http://www.pobox.com/~mra

Re: How to tell how much to expect from a fd

[Eric Lammerts]

On 27 Mar 2002, Mark Atwood wrote:

> Does there exist a fcntl or some other way to tell how much data is
> "ready to be read" from a fd?

int val;
ioctl(fd, FIONREAD, &val);

See tcp(7).

Eric

Re: How to tell how much to expect from a fd

[David Schwartz]

On 27 Mar 2002 18:52:39 -0800, Mark Atwood wrote:
>
>Does there exist a fcntl or some other way to tell how much data is
>"ready to be read" from a fd?
>
>I'm doing this thing where I make the fd non-blocking, select on it,
>and then read on it into a buffer that I am pregrowing with realloc.
>
>When the high water mark is up to the top of the buffer, I realloc the
>buffer to make it bigger.  At present, I'm just adding a constant
>value to the buffer size each time I need to do this, but if there was
>a way to easily tell how much was "ready to be read" from the fd.
>
>It's not necessary to be exact. If more becomes available between the
>time I do this wanted magic and do the read, read's 3rd parameter will
>keep me safe, and if it's too low, like if a dup of the fd already
>snarfed the data, also no big deal, I'm non-blocking and check the
>return value.
>
>So, is this "nice to have" available?

	It is possible that you are the one-in-a-million case that really needs 
this, but the vast majority of the time people ask for this, they don't 
really want it.

	Consider two very important points:

	First, by the time you get this information, it's obsolete. If more data 
becomes available in-between when you make this call and when you attempt to 
read, you'll take a double penalty. You'll need an extra 'read' later to get 
the rest and your next poll/select will break out immediately (which can be 
very expensive if you're dealing with a large number of fds).

	Second, this would double the number of system calls you need to read the 
data from the socket. There's almost no conceivable scenario in which it's 
worth the cost of doing this when you can either keep a buffer that's a bit 
too large around or copy it into a right-sized buffer and you can choose 
which option after you know how many bytes you got.

	DS

Re: How does "alias ethX drivername" in modules.conf work?

[Jim Roland]

It's pretty simple.  If you have no special options to pass to the module:

alias eth0 modulename
(example for 3C905B-TX:  alias eth0 3c90x)


Mark Atwood wrote:

>I'm trying to figure out how "alias ethX" works in /etc/modules.conf
>
>Is it some "magic" in depmod / modprobe? And how is the network
>interface identifier then passed into the module when it loads?
>
>A nice whitepaper or doc or a few pointers or handholding would be
>apprecated.
>

Re: How does "alias ethX drivername" in modules.conf work?

[Jim Roland]

It's pretty simple.  If you have no special options to pass to the module:

alias eth0 modulename
(example for 3C905B-TX:  alias eth0 3c90x)


Mark Atwood wrote:

>I'm trying to figure out how "alias ethX" works in /etc/modules.conf
>
>Is it some "magic" in depmod / modprobe? And how is the network
>interface identifier then passed into the module when it loads?
>
>A nice whitepaper or doc or a few pointers or handholding would be
>apprecated.
>

How to hack a network driver to use a specific ethX (was Re: How does "alias ethX drivername" in modules.conf work?)

[Mark Atwood]

Tim Jansen <tim@tjansen.de> writes:
> On Friday 03 August 2001 23:29, Mark Atwood wrote:
> > I'm trying to figure out how "alias ethX" works in /etc/modules.conf
> > Is it some "magic" in depmod / modprobe? And how is the network
> > interface identifier then passed into the module when it loads?
> 
> If some user-space app accesses ethX the kernel calls "/sbin/modprobe ethX". 
> The alias in /etc/modules.conf just gives ethX the name of the real module. 
> The interface identifier isn't passed to the module, you have to initialize 
> your interfaces in the right order (or set it using an option for modprobe, 
> but I don't whether any drivers support setting the interface identifier).

Are their any examples of drivers that can set the interface identifier?

If it possible that a driver may do so, does that mean that the kernel
can handle interface identifiers being set "out of order"?


My problem stems the following situation:

  eth0 is an "ordinary" PCI hme ethernet device. That works just fine.

  eth1 is a weird device that is still under hardware development,
   and, depending on the phase of the moon and the favor of the Gods,
   sometimes comes up and sometimes doesnt

   there is a line in /etc/modules that looks like

    alias eth1 weirddevice

  eth2 is to be a hot plugged PCMCIA ethernet device


In the cases when "weirddevice" properly comes up, I can
 see it's driver in lsmod,
 see it's interface in ifconfig as eth1,
 and then when I plug in the PCMCIA card
  it gets eth2, and works fine

In the cases when "weirddevice" doesnt come up, I can
  still see it's driver in lsmod
   but it's marked "(unused)"
  dont see it in ifconfig
  and then when I plug in the PCMCIA card
   it gets eth1,
    i can see the module driver in lsmod
    i can see the interface in eth1
   BUT
    it doesnt work, and the cardmgr error log says that cardmgr keeps trying to reset the card to make it work


I suspect that the cardmgr is loading the correct card driver module,
but then some sort of argument is happening under the hood, as the
card driver knows that it registered eth1, but the modules.conf has
the "alias eth1 weirddevice" line.

I'm feeling that the easiest way to make my headache go away is be
able to somehow insist to each network driver "YOU go in eth1, no
matter what, and YOU go in eth2, no matter if their is a eth1 or not".

I cannot do this by MAC address, because I have a small herd of these
boxes, with different MACs for each interface in each box, and, if my
employers dreams come true, there will soon enough be hundreds and
then thousands of these boxes.

If it's not too terribly hard to modify a network driver to go to an
interface specified as a module option, I can probably hack that into
the module drivers (I do have the source to them, thank gods.)

-- 
Mark Atwood   | I'm wearing black only until I find something darker.
mra@pobox.com | http://www.pobox.com/~mra

Re: How does "alias ethX drivername" in modules.conf work?

[Stuart Lynne]

>  >>> Lets assume that eth0-eth3 are not initialized at boot time and
>  >>> your init scripts attempt to initialize eth4 ...
> 
> I gather that I misunderstood what you were saying above, so let me
> clarify what I now understand by your comments:
> 
>  1. You are assuming a broken set of init scripts. Specifically,
>     they load the individual modules manually by the name of the
>     module, rather than stating that you wish to initialise a
>     particular interface and letting kmod sort out the correct
>     module.
> 
>     If this is your assumption, then you've created an artificial
>     situation that by its very nature is broken and unreliable.
> 

>  >>> To avoid such problems one probably should add a lot of
>  >>> pre-install parameters in modules.conf.
> 
>  >> What problems?
> 
>  > Described above.
> 
> What KERNEL problems then? I don't see any yet.

So not being able to reliable map ethernet devices to names is a feature
not a bug .... 

It *should* be possible to reliably name devices without having to rely
on order dependant initialization.

-- 
                                            __O 
Lineo - For Embedded Linux Solutions      _-\<,_ 
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <sl@fireplug.net>         www.lineo.com         604-461-7532

Re: How does "alias ethX drivername" in modules.conf work?

[Bill Nottingham]

Stuart Lynne (sl@fireplug.net) said: 
> So not being able to reliable map ethernet devices to names is a feature
> not a bug .... 

With reasonable scriptage and 'nameif', it's doable. Only for
ethernet at the moment, however (and I haven't actually implementing
something that does this.)  But it *is* doable.

Bill

Re: How does "alias ethX drivername" in modules.conf work?

[Greg KH]

On Tue, Aug 07, 2001 at 10:36:25PM -0400, Bill Nottingham wrote:
> Stuart Lynne (sl@fireplug.net) said: 
> > So not being able to reliable map ethernet devices to names is a feature
> > not a bug .... 
> 
> With reasonable scriptage and 'nameif', it's doable. Only for
> ethernet at the moment, however (and I haven't actually implementing
> something that does this.)  But it *is* doable.

With only adding one line to the current linux-hotplug scripts, a
co-worker of mine enabled reliable mapping that isn't dependent on pci
scanning, or hotplugging of pci cards.  He used nameif and a table of
MAC addresses that map to the name he wanted.


greg k-h

Re: How does "alias ethX drivername" in modules.conf work?

[Matt_Domsch]

> Userspace init scripts point the finger at kernel, saying "there
> is no good and no well documented mapping method". Kernel points
> its finger at userspace, saying "this is the way we do it" and
> "we cant guarantee a perfect 100% mapping solution, so we're not
> even going to try for 90%" and "futz with your drivers and
> modules.conf and init scripts till you get something that
> works".

Ethtool can help out initscripts, and I've recently submitted patches to the
appropriate maintainers for the eepro100 (both in-kernel and Donald's),
acenic, bcm5700, Intel e100 and e1000, so those cards report back their
assignments when using ethtool.  Several other drivers already have this
support in them.

ethtool -i eth0 returns:
driver: eepro100
version: someversionstring
firmware-version: someversionstring
bus-info: 00:05.0

Now you know at least that eth0 is an eepro100-driven card, and it's a PCI
device at 00:05.0.  lspci can give you the name of the card then if you want
it.
This helps, but doesn't solve the problem of knowing, looking from the
outside, which physical card is considered eth0, or conversely, what ethX
assignment did my embedded NIC get.  On x86, the $PIR PCI IRQ Routing Table
provided by BIOS can help.  It describes embedded (Slot 0) or add-in (Slot
x>0) cards using slot names likely silkscreened on the motherboard or
numbered externally.

Slot 0: PCI 00:05.
Slot 0: PCI 00:06.
Slot 0: PCI 00:08.
Slot 0: PCI 00:0f.
Slot 1: PCI 00:07.
Slot 2: PCI 03:08.
Slot 3: PCI 03:09.
Slot 4: PCI 03:0a.
Slot 5: PCI 03:0b.
Slot 6: PCI 0d:0c.
Slot 7: PCI 0d:0d.

A little sorting is required, as the table doesn't include (or for it's
purposes need to include) the PCI function number of multi-function devices,
but at least you know what's embedded and what's add-in now, and what
physical PCI slot.

I'm continuing to flesh out this idea, so if you've got thoughts for how to
make good use of this info, please let me know.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer
Dell Linux Solutions
www.dell.com/linux
#2 Linux Server provider with 17% in the US and 14% Worldwide (IDC)!
#3 Unix provider with 18% in the US (Dataquest)!