There's a right way to enumerate network interfaces and a wrong way (which is dependent on the language you're using for enumeration - the wrong way is assuming that eth0 is the only network device).
Bear in mind that the new convention is not entirely dissimilar to how WiFi cards have worked on Linux for some time, so the only things that will break will be things that:
a) Assume eth0 instead of enumerating devices
b) Have a legitimate reason for using eth0 only (I can't think of one, but I wouldn't be surprised if one existed)I got around to trying out Gentoo, which has amazing documentation that really drills down into what you're doing and why. That's when I ran ifconfig and iwconfig for the first time and realized I probably would have been using Linux years earlier if I had known how to find out that my NIC was wlan0.
So I'd say referencing eth0 throughout is fine, as long as at the beginning you take the time to point out that it may not be eth0, and more importantly, how to find out what it is.
If for example you're running Linux on a Macbook Air you have no eth0 by default. Ergo, documentation referencing it is technically incorrect - it would be possible to say badly written at this point but that's even more pedantic than your comment ;)
Everyone else has separate device namespaces for - you might have an fxp0 , rl0, hme0, etc. on any BSD or Solaris machine.
Rather than looking in /dev, they really ought to be parsing the output of ifconfig -a.
2. You mean (IIRC) 'ip link show'. ifconfig on linux isn't maintained, and breaks in a bunch of situations (Aliases on VLANs on bonds, for one)
3. And you should of course use python-procfs or your preferred equiv, not parse the output of other tools.
On the article in general: can't you use /dev/by-manufacturer these days or similar? I haven't been working on OS stuff recently so can't remember if that became standard.
> 2. You mean (IIRC) 'ip link show'. ifconfig on linux isn't maintained, and breaks in a bunch of situations (Aliases on VLANs on bonds, for one)
This seemingly simple change seems to be taking forever to gain traction; "use `ip` for network config on linux".
There is so much googlable stuff instructing one to use ifconfig, route, etc. that it seems to self perpetuate. I often find people telling others that "you can't do that in Linux", when the real answer is along the lines of "you can't do that with the route command" (to give an example that I've seen a few times recently, route can't manipulate routing tables)
Not all add-in cards have a method to expose their Linux interface name(s) to external port mapping. biosdevname may provide incorrect names for such. Discussions are ongoing on the netdev mailing list to standardize a method of exposing such mapping.
Seems like this would be kind of a deal-breaker for any wholesale move like this. I'd be fairly surprised if this got any widespread adoption anytime soon.
http://linux.dell.com/files/whitepapers/nic-enum-whitepaper-...
NAME em - Intel PRO/1000 10/100/Gigabit Ethernet device
http://www.openbsd.org/cgi-bin/man.cgi?query=em&apropos=...
Edit: Reading more of that thread I may be off-base here, but naming a network interface em that's not powered by certain Intel chipsets will be very confusing to BSD users. Just my 2 cents.
On other distributions, "udev" accomplishes the same thing.
The only point when interface naming is arbitrary is at installation time, then it stays the same forever.
Not only this will add confusion by introducing a bunch of new names for network interfaces, it will also break applications that rely on them being called "ethX".
It will also make it impossible to manually assign names to interfaces. For instance, if you have a configuration that uses an embedded interface and you want to add another interface on a card, you can manually assign the same "ethX" name to it, but not if the names depend on the physical characteristics of the hardware.
Ability to rename: http://lists.us.dell.com/pipermail/linux-poweredge/2010-Nove...
Why the eth prefix can't be used: http://lists.us.dell.com/pipermail/linux-desktops/2011-Febru...
More background: http://domsch.com/blog/?p=455
If the machine is coldstarted then previous devices could be randomly reshufled. Imagine you have a datacenter with 100 machines and you have some kind of provisioning scheme where you coldstart them often. It would be a nightmare having to run ethtool -p <dev> and replug cables.
We have solved the problem by providing a consistent algorithm of sorting all the devices in a udev callback. We have a known set of hardware so we know which cards are add-ons (our machines have 4+ eth ports) and which ones are built-ins. So it works out, however, it would be nice to generalize it somehow.
But that's because PCI bus walk order doesn't change across reboots.
While udev is more universal, iftab felt elegant and unixy.
~$ sudo egrep -Irl 'eth[0-9]' /etc /usr 2>/dev/null |wc -l
27My hope is that consumer distributions will stop presenting the device name and configuration at all. When I'm trying to show new Ubuntu users how to connect to wired and wireless networks, it's annoying to have to explain what NetworkManager means by "Auto eth0".
https://bugs.launchpad.net/ubuntu/+source/network-manager/+b...
Really??