Guus Sliepen <g...@debian.org> writes: > Ok, it should be clear now that the new way of naming interfaces is not > ideal, but the older ways weren't either. Let's have a look at what we > want: > > - A simple name for systems with a single Ethernet and/or Wireless > interface (the simple desktop/laptop scenario). > - A consistent naming scheme for interfaces in a system with multiple Ethernet > interfaces (the server scenario). > - Not having interface names change after reboots.
I got to ask: Why? We do not have stable names for e.g. disks. Why do we need it for network devices? Yes, yes, I know you can screw up your system by configuring a dynamic device name in /etc/network/interfaces. But I believe you should be allowed to. Just like you can screw up your system by referring to a dynamic block device name in /etc/fstab. Leave the kernel network device names alone. Let them be dynamic. Just document that fact. "stable device name" is not the problem. The problem is associating configuration with the correct physical device. Note that this is not an issue at all until you add some static network configuration. Which makes it a non-issue for most end user systems, regardless of the number or type of of network devices. For static network configurations on systems with multiple interfaces, the correct and only logical place for the device association is with the rest of the network configuration. If you use NetworkManager, then it is up to NetworkManager to match it with a specific network device - if required. The rest of the system does not need to care. The remaining problem is to make ifupdown do device matching on other (and hopefully more stable) attributes than the device name. Bjørn
