On Tue, 24 Mar 2009, Matt Domsch wrote:

quoted text
> You may recall http://lkml.org/lkml/2006/9/29/268, wherein I described
> network device enumeration and naming challenges, and several possible
> fixes.  Of these, Fix #1 (fix the PCI device list to be sorted
> breadth-first) has been implemented in the kernel, and Fix #3 (system
> board routing rules) have been implemented on Dell PowerEdge 10G and
> 11G servers (11G begin selling RSN).
>
> However, these have not been completely satisfactory.  In particular,
> it keeps getting harder and harder to route PCI-Express lanes to
> guarantee the same ordering between a depth-first and breadth-first
> walk, and it turns out, that isn't sufficient anyhow.
>
>
> Problem:  Users expect on-motherboard NICs to be named eth0..ethN.  This can be difficult to achieve.

I dispute this statement.

I have several hundred servers that have the on-motherboard NICs as the 
last ones.

anyone who's been making the assumption you describe will have been 
running into problems for many years.

it's just not a valid assumption.

quoted text
> Ethernet device names are initially assigned by the kernel, and may be
> changed by udev or nameif in userspace.  The initial name assigned by
> the kernel is in monotonically increasing order, starting with eth0.
> In this instance, the enumeration directly leads to an assigned name.
>
> Complications:
>
> 1) Devices are discovered, and presented to the kernel for name
>   assignment, based on several factors:
>
>   a) the kernel hotplug mechanism emits events for udev to catch, to
>
>
>   b) udev may run modprobes in parallel.  It guarantees that the
>
>      To get any consistent ordering now, one of two things must
>      happen:
>
>      i) drivers must be loaded before udev begins loading drivers
>         (either very early in initscripts, or in the inital ramdisk).
>     ii) something must "fix up" the kernel-assigned names after
>         udev's modprobes complete.  udev does this as well.
>
> 2) udev may have rules to change the device names.  This is most often
>   seen in the '70-persistent-net.rules' file.  Here we have
>   additional challenges:
>
>   a) this does not exist the first time devices are discovered; the
>
>   b) it introduces state (MAC addresses) to the system, on a system
>
>   c) udev may not always be able to change a device's name.  If udev
>

not everyone uses udev. I compile the nessasary drivers into the kernel 
and don't need udev to get interfaces.

quoted text
> 3) End users have the (reasonable?) expectation that NIC ports

as noted above, only some users have this unrealistic expectation.

quoted text
> 4) When adding a network card to an existing system, what should the
>   ports on the new card be named?  If it is added, they will be named
>   ethN+1... above the existing named cards.  This means a (new)
>   add-in card in PCI slot 3 may have ports named eth5 and eth6, while
>   an add-in card in PCI slot 5 may have ports named eth2 and eth3.
>   This is not intuitive.

this approach causes serious problems in a few cases, including

1. a NIC goes bad and you replace it. now all the configs change

2. you reinstall a box and it's interface names change.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html