Colin Watson [2012-01-31 14:29 +0000]: > There are certainly some advantages to enabling biosdevname by default. > On systems that support it, it makes it somewhat easier to write scripts > that predictably apply to a certain interface without having to mess > around with looking up interfaces by MAC address.
I agree that in many situations where you work with multiple interfaces, stable names would be much preferrable. > [...] > Secondly, while as I said above I agree that enabling biosdevname solves > some problems, it seems likely that this change will cause problems of > its own. For example, any software that needs to know about network > interfaces (let's say it listens on a particular interface) might well > default to eth0 Stephane confirmed that this is an actual problem in his reply. This situation has a striking similarity with stable names for block, sound, and input devices. There was a time when the "classic" names like hda/sda went away entirely, but this situation never lasted very long because of pretty much exactly this problem: too much software making hardcoded assumptions about device names. That's why the current policy eventually distilled itself: it is actively wrong, and now even unsupported by udev to rename devices, so schemas like "sd[a-z][0-9]" or input/event* will always continue to work. Instead, the only thing you can and should do is to create aliases in the form of symlinks (/dev/disks/by-uuid/, /dev/input/by-id/, etc.) Now, unfortunately network devices have always been special in that they are not proper character devices, so symlinks don't work. But as the kernel supports renaming devices, is there any way of providing the same devices under two names, i. e. adding aliases instead of ifrename? interfaces(5) already supports mappings and renames, so from my naive POV it seems this shouldn't be too hard to get a concept of aliases? Perhaps even the Dell folks would be interested in this, as it would remove the main blocker for adoption? If we can get this to work, then I see no reason to not introduce biosdevname, as it would not break any existing setup, local configuration, or hardcoded assumption. Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
