On Wednesday 2010-01-13 18:46, Domsch, Matt wrote:
>>
>> I am less than enthusiastic about the idea as well. I've come across
>> numerous userspace scripts and whatnot that have enough trouble with the
>> default route not being through "eth0" let alone anything more
>> complex. Aliases are going to cause a lot of problems for a lot of
>> people for little actual gain.
>
>The "actual gain" is to provide a deterministic method of naming
>network devices, in a stateless manner (e.g. w/o hard-coding MAC
>addresses). We don't have deterministic naming today. It only gets
>worse as we add more NIC ports.
>
>The kernel doesn't provide deterministic naming.
>
>Renaming from ethN to ethM is racy; often we wind up with devices named
>'eth0_rename'.
>
>Stephen noted (echoed in Bernd's comment) that the ethN namespace is
>effectively an ABI (and certainly the 15-character IFNAMESZ is).
>Userspace tools today expect ethN names.
Let's get things straight at least. Userspace does not expect eth#.
You may get away with claiming feature-incompleteness if your program
has no idea of tun#, sit# gre# and such, but there is also wlan#,
tap#, and others that are a link/ether device. If a program relies on
eth#, it is broken and should either be fixed or left dead in its
corner.
>So:
>a) we can't rely on ethN being meaningful from boot.
>b) we can't rename ethN to ethM without racing
In practice you should be.
rename eth0 -> eth0_rename
do {
} while (rename eth0_rename eth1 == EEXIST);
Yes it is a race, but eth1 will move out of the way - given you have
udev scripts properly set up so as to rename any unknown interface
out of the way to make room for eth1. Interfaces which do have a
mapping will get renamed anyway.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
