[networking-guide] master: Naming Schemes Hierarchy is now a section (94a73f9)

stephenw at fedoraproject.org stephenw at fedoraproject.org
Tue Jul 29 19:06:14 UTC 2014


Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git

On branch  : master

>---------------------------------------------------------------

commit 94a73f9ccb3abffb1a947d59d558f96c319adfb6
Author: Stephen Wadeley <swadeley at redhat.com>
Date:   Tue Jul 29 21:05:49 2014 +0200

    Naming Schemes Hierarchy is now a section
    
    incorporate the info from
    "Naming Schemes for Network Interfaces"


>---------------------------------------------------------------

 en-US/Consistent_Network_Device_Naming.xml |   55 +++++++---------------------
 1 files changed, 14 insertions(+), 41 deletions(-)

diff --git a/en-US/Consistent_Network_Device_Naming.xml b/en-US/Consistent_Network_Device_Naming.xml
index 1e75ba5..c509d62 100644
--- a/en-US/Consistent_Network_Device_Naming.xml
+++ b/en-US/Consistent_Network_Device_Naming.xml
@@ -15,75 +15,48 @@
   <para>
     In &MAJOROSVER;, <systemitem class="daemon">systemd</systemitem> and <application>udev</application> support a number of different naming schemes. The default is to assign fixed names based on firmware, topology, and location information. This has the advantage that the names are fully automatic, fully predictable, that they stay fixed even if hardware is added or removed (no re-enumeration takes place), and that broken hardware can be replaced seamlessly. The disadvantage is that they are sometimes harder to read than the <interface>eth0</interface> or <interface>wlan0</interface> names traditionally used. For example: <interface>enp5s0</interface>.
   </para>
-  <bridgehead id="bh-Naming_Schemes_for_Network_Interfaces">Naming Schemes for Network Interfaces</bridgehead>
-  <para>
-    The following different naming schemes for network interfaces are now supported by <application>udev</application> natively:
-    <orderedlist>
-      <listitem>
-        <para>
-    Names incorporating Firmware or BIOS provided index numbers for on-board devices (example: <literal>eno1</literal>)
-        </para>
-      </listitem>
-  <listitem>
-    <para>
-    Names incorporating Firmware or BIOS provided PCI Express hotplug slot index numbers (example: <literal>ens1</literal>)
-    </para>
-  </listitem>
-    <listitem>
-      <para>
-    Names incorporating physical location of the connector of the hardware (example: <literal>enp2s0</literal>)
-      </para>
-    </listitem>
-  <listitem>
-    <para>
-    Names incorporating the interface's MAC address (example: <literal>enx78e7d1ea46da</literal>)
-    </para>
-  </listitem>
-  <listitem>
-    <para>
-   The traditional unpredictable kernel-native <interface>eth<replaceable>X</replaceable></interface> naming (example: <literal>eth0</literal>)
-    </para>
-  </listitem>
-</orderedlist>
-</para>
-<bridgehead id="bh-Naming_Schemes_Hierarchy">Naming Schemes Hierarchy</bridgehead>
-<para>
-By default, <systemitem class="daemon">systemd</systemitem> will name interfaces using the following policy to apply the naming schemes listed above :
+
+<section id="sec-Naming_Schemes_Hierarchy">
+<title>Naming Schemes Hierarchy</title>
+
+   <para>
+   By default, <systemitem class="daemon">systemd</systemitem> will name interfaces using the following policy to apply the supported naming schemes:
 <itemizedlist>
   <listitem>
     <para>
-    <emphasis role="bold">Scheme 1:</emphasis> Names incorporating Firmware or BIOS provided index numbers for on-board devices (example: <literal>eno1</literal>), are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 2;
+    <emphasis role="bold">Scheme 1:</emphasis> Names incorporating Firmware or BIOS provided index numbers for on-board devices (example: <literal>eno1</literal>), are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 2.
     </para>
   </listitem>
   <listitem>
     <para>
-     <emphasis role="bold">Scheme 2:</emphasis> Names incorporating Firmware or BIOS provided PCI Express hotplug slot index numbers (example: <literal>ens1</literal>) are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 3;
+     <emphasis role="bold">Scheme 2:</emphasis> Names incorporating Firmware or BIOS provided PCI Express hotplug slot index numbers (example: <literal>ens1</literal>) are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 3.
     </para>
   </listitem>
   <listitem>
     <para>
-       <emphasis role="bold">Scheme 3:</emphasis> Names incorporating physical location of the connector of the hardware (example: <literal>enp2s0</literal>), are applied if applicable, else falling directly back to scheme 5 in all other cases;
+       <emphasis role="bold">Scheme 3:</emphasis> Names incorporating physical location of the connector of the hardware (example: <literal>enp2s0</literal>), are applied if applicable, else falling directly back to scheme 5 in all other cases.
     </para>
   </listitem>
   <listitem>
     <para>
-       <emphasis role="bold">Scheme 4:</emphasis> Names incorporating interface's MAC address, is not used by default, but is available if the user chooses;
+       <emphasis role="bold">Scheme 4:</emphasis> Names incorporating interface's MAC address (example: <literal>enx78e7d1ea46da</literal>), is not used by default, but is available if the user chooses.
     </para>
   </listitem>
     <listitem>
     <para>
-      <emphasis role="bold">Scheme 5:</emphasis> The traditional unpredictable kernel naming scheme, is used if all other methods fail.
+      <emphasis role="bold">Scheme 5:</emphasis> The traditional unpredictable kernel naming scheme, is used if all other methods fail (example: <literal>eth0</literal>).
     </para>
   </listitem>
-
 </itemizedlist>
-
 </para>
 
+
    <para>
      This policy, the procedure outlined above, is the default. If the system has <application>biosdevname</application> enabled, it will take precedence. Note that enabling <application>biosdevname</application> requires passing <command>biosdevname=1</command> as a command line parameter except in the case of a Dell system, where <application>biosdevname</application> will be used by default as long as it is installed. If the user has added <application>udev</application> rules which change the name of the kernel devices, those rules will take precedence too.
    </para>
 
+   </section>
+
      <section id="sec-Understanding_the_Device_Renaming_Procedure">
   <title>Understanding the Device Renaming Procedure</title>
 <para>



More information about the docs-commits mailing list