Re: Network Device Naming mechanism and policy

[Scott James Remnant]

On Tue, 2009-03-24 at 10:46 -0500, Matt Domsch wrote:

>    b) udev may run modprobes in parallel.  It guarantees that the
>       events and modprobes are begun in order, but makes no guarantee
>       that one event's modprobe completes before beginning a second
>       modprobe.  This leads to naming races in the kernel, as drivers
>       begun in parallel, which discover their own devices, present
>       them to the kernel for name assignment.
> 
Also bear in mind that a module completing init() does not necessarily
mean that the interfaces have been created.  If the driver requires
firmware, it will call out to userspace, and may not register the
interface until well afterwards.

One could even construct a pathological case where only a virtual device
was registered, and userspace was required to add logical interfaces
(most likely in a udev rule).

> 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
>       naming may be incorrect during first discovery, leading to the
>       names being permanently incorrect (unless this file is edited).
> 
Well, the obvious fix to this is to make sure the names are always
correct :)

>    c) udev may not always be able to change a device's name.  If udev
>       uses the kernel assignment namespace (ethN), then a rename of
>       eth0->eth1 may require renaming eth1->eth0 (or something else).
>       Udev operates on a single device instance at a time, it becomes
>       difficult to switch names around for multiple devices, within
>       the single namespace.
> 
Actually udev handles this by using a temporary name.  When renaming
eth0->eth1 it actually uses an intermediate name first.  This allows it
to simultaneously swap eth0<->eth1 since one unblocks the other
(actually both unblock each other).

There is a failure case where two devices both end up trying to get the
same name, in which case one will lock with a "_rename" name.  There was
an early debate in Ubuntu when we first wrote this code about using
later names (eth2, eth3, etc.) but we realised that just hides the
problem (and it happens again if you plug in a pccard or something that
wants eth2).

Since this is always a bug, making the problem visible was a "good
thing".

> biosdevname (http://linux.dell.com/projects.shtml#biosdevname) takes a
> stab at this.  It can be integrated into udev, such that the
> 70-persistent-net.rules file is never used, and the naming for each
> device comes from several different policies.  Its primary drawback is
> that it changes the device namespace, which some sysadmins, and tools,
> may not like.  Names for devices become eth_s0_0 for the first
> onboard NIC, eth_s0_1 for the second; eth_s3_3 for the fourth port
> on PCI Slot #3, etc.
> 
While this works for PCI slots, it already doesn't scale to other buses.
For example what slot number is the pccard slot?  If you have two
different pccard devices, would they get assigned the same name (udev
currently assigns them different names).

Now consider USB.  Would the device name change depending on which USB
port you plugged it into?  Or is USB just a single slot, in which case
what happens when you have two USB ethernet devices?

The Apple USB Ethernet device in my iPhone is not the USB Wireless
adapter I own, both have very different networking configurations.

it's not ideal in the laptop world.  Consider a user with two different 

> Option 3: INSERT YOUR IDEA HERE
> 
I quite liked the idea of /dev/eth0, then we could just use symlinks.

Scott
-- 
Scott James Remnant
scott@xxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part