netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Narendra K <Narendra_K@dell.com>
To: anaconda-devel-list@redhat.com
Cc: netdev@vger.kernel.org, matt_domsch@dell.com,
	charles_rose@dell.com, sandeep_k_shandilya@dell.com,
	jordan_hargrave@dell.com, shyam_iyer@dell.com
Subject: [PROPOSAL]: Support Alternate Network Device Naming Schemes
Date: Fri, 27 Nov 2009 03:11:01 -0600	[thread overview]
Message-ID: <20091127091100.GA23760@mock.linuxdev.us.dell.com> (raw)


We have been having discussions in the netdev list about creating multiple names for the network interfaces to bring determinism into the way network interfaces are named in the OSes. In specific, "eth0 in the OS does not always map to the integrated NIC Gb1 as labelled on the chassis".  

http://marc.info/?l=linux-netdev&m=125510301513312&w=2 - (Re: PATCH: Network Device Naming mechanism and policy)
http://marc.info/?l=linux-netdev&m=125619338904322&w=2 - ([PATCH] udev: create empty regular files to represent net)

As a result of those discussions, we propose an installer based solution.

Installers as of now allow the discovered network interfaces to be configured. This solution proposes to provide an option for the users to either retain the default naming convention that the kernel now has, i.e ethN names or rename the network interfaces based on the chassis label, MAC addresses, Driver name and any other naming convention. Here is how the modified network configuration wizard would look during the os installation process - 


---------- Network Configuration ------------------------

Default [ ] |  SMBIOS Names [x]     |  Driver Names []  | MAC Names []
-----------------------------------------------------------------------
 eth0       | Addin_NIC_1           | ice0              |
-----------------------------------------------------------------------
 eth1       | Embedded_NIC_1        | bce0              |       
-----------------------------------------------------------------------
 eth2       | Embedded_NIC_2        | bce1              |       
-----------------------------------------------------------------------
 eth3       | Embedded_NIC_3        | bce2              |            
-----------------------------------------------------------------------
 eth4       | Embedded_NIC_4        | bce3              |  
-----------------------------------------------------------------------

                                                        ------------
                                                        | Next     |
                                                        ------------

[ ice0 - Intel Controller 0, bce0 - Broadcom Controller 0 ] 

1. In addition to the default ethN names the user can check against the available naming conventions and the wizard would show the names the interfaces will be renamed to.
2. The moment the user hits the Next button all interfaces are renamed as per the Naming convention they have selected.
3. Any further network communication would  be using the new names.
4. Ifconfig would show names like "Embedded_NIC_1" and not eth0 etc.

This way the OS names of network interfaces would have a co-relation to the chassis names. Irrespective of what the OS names the integrated port one, i.e eth0 or eth1, Embedded_NIC_1 will always refer to the integrated port 1, bringing in determinism.

Additional Reference:
http://marc.info/?l=linux-hotplug&m=125692284431543&w=2
http://marc.info/?l=linux-netdev&m=125683519310462&w=2
http://marc.info/?l=linux-netdev&m=125754944814387&w=2
http://marc.info/?l=linux-hotplug&m=125536996902867&w=2

With regards,
Narendra K

             reply	other threads:[~2009-11-27  9:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-27  9:11 Narendra K [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-11-27  9:42 [PROPOSAL]: Support Alternate Network Device Naming Schemes Narendra K
2009-11-30 17:07 ` Jon Masters
2009-11-30 18:34 ` Bill Nottingham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091127091100.GA23760@mock.linuxdev.us.dell.com \
    --to=narendra_k@dell.com \
    --cc=anaconda-devel-list@redhat.com \
    --cc=charles_rose@dell.com \
    --cc=jordan_hargrave@dell.com \
    --cc=matt_domsch@dell.com \
    --cc=netdev@vger.kernel.org \
    --cc=sandeep_k_shandilya@dell.com \
    --cc=shyam_iyer@dell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).