summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLennartPoettering <mzninuv@0pointer.de>2013-01-07 22:19:48 +0000
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>2018-12-11 10:58:39 +0100
commitce7c9f453aa39c8148e1d356d1fe79cfee1740a8 (patch)
tree391d6461292f6efefb43e45b55c638283c945d70
parent128faa63f25a5ca0f1ac4747fdb2d6271543c55b (diff)
downloadsystemd-ce7c9f453aa39c8148e1d356d1fe79cfee1740a8.tar.gz
systemd-ce7c9f453aa39c8148e1d356d1fe79cfee1740a8.tar.bz2
systemd-ce7c9f453aa39c8148e1d356d1fe79cfee1740a8.zip
-rw-r--r--docs/PredictableNetworkInterfaceNames.moin4
1 files changed, 2 insertions, 2 deletions
diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin
index 840741396a..15e6aa89f3 100644
--- a/docs/PredictableNetworkInterfaceNames.moin
+++ b/docs/PredictableNetworkInterfaceNames.moin
@@ -8,7 +8,7 @@ The classic naming scheme for network interfaces applied by the kernel is to sim
To fix this problem multiple solutions have been proposed and implemented. For a longer time udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not available; the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly on all kinds of virtualization solutions. The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same "ethX" namespace, a race condition with all kinds of weird effects. As a result support for this has been removed from systemd/udev a while back.
-Another solution that has been implemented is "biosdevname" which tries to find fixed slot topology information in certain firmware interfaces and uses them to assign fixed names to interfaces which incorporate their physical location on the mainboard. (Unfortunately biosdevname did a lot more than this which is more problematic).
+Another solution that has been implemented is "biosdevname" which tries to find fixed slot topology information in certain firmware interfaces and uses them to assign fixed names to interfaces which incorporate their physical location on the mainboard. In a way this naming scheme is similar to what is already done natively in udev for various devices via /dev/*/by-path/ symlinks. biosdevname departs from the low-level kernel device identification schemes that udev generally uses for these symlinks, and instead invents its own enumeration schemes.
Finally, many distributions support renaming interfaces to user-chosen names (think: "internet0", "dmz0", ...) keyed off their MAC addresses or physical locations as part of their networking scripts. This is a very good choice but does have the problem that it implies that the user is willing and capable of choosing and assigning these names.
@@ -16,7 +16,7 @@ We believe it is a good default choice to generalize the scheme pioneered by "bi
== What has changed v197 precisely? ==
-With systemd 197 we have moved a scheme similar to biosdevname (but generally more powerful) into systemd/udev proper. A number of different naming schemes for network interfaces are now supported by udev natively:
+With systemd 197 we have moved a scheme similar to biosdevname (but generally more powerful, and closer to kernel-internal device identification schemes) into systemd/udev proper. A number of different naming schemes for network interfaces are now supported by udev natively:
1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: {{{eno1}}})
2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: {{{ens1}}})