netdev - RE: [PATCH] udev: create empty regular files to represent net interfaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <EDA0A4495861324DA2618B4C45DCB3EE589662@blrx3m08.blr.amer.dell.com>
Date:	Thu, 29 Oct 2009 22:14:08 +0530
From:	<Narendra_K@...l.com>
To:	<greg@...ah.com>, <Matt_Domsch@...l.com>
Cc:	<kay.sievers@...y.org>, <dannf@...com>,
	<linux-hotplug@...r.kernel.org>, <netdev@...r.kernel.org>,
	<Jordan_Hargrave@...l.com>, <Charles_Rose@...l.com>,
	<bhutchings@...arflare.com>
Subject: RE: [PATCH] udev: create empty regular files to represent net interfaces

>> Netdev team - are you in agreement that having multiple names to 
>> address the same netdevice is a worthwhile thing to add, to allow a 
>> variety of naming schemes to exist simultaneously?  If not, 
>this whole 
>> discussion will be moot, and my basic problem, that the ethX naming 
>> convention is nondeterministic, but we need determinism, remains 
>> unresolved.
>
>I'm still totally confused as to why you think this.  What is 
>wrong with what we do today, which is name network devices in 
>a deterministic manner by their MAC in userspace?  That name 
>goes into the kernel, and everyone uses the same name and is happy.

The interface name as assigned by the OS is determined by how the
interface is named first during the OS installation. This name is made
persistent by associating the name with it's MAC address in userspace,
either by udev or ifcfg-eth files. In cases where there are one or more
add-in cards along with one or more integrated cards (Lan on
Motherboard), the integrated port 1, which is designated as Gb1 on the
chassis may or may not get the name "eth0". And that is the customer
expectation, most of the times.
Unattended installs and large scale image based installs are the most
affected scenarios. 

>If you don't like naming by MAC, then pick some other 
>deterministic naming scheme that works for your hardware and 
>write udev rules for it.
>
>You could easily name them in a way that could keep the lowest number
>(eth0) for the lowest PCI id if you so desired and your BIOS 
>guaranteed it.
>

This is how the lspci tree view on a PER710 (PowerEdge R710) server with
Four BCM5709 integrated NIC ports and One add-in Intel NIC port looks
like. The integrated ports are always found before the add-in nic (or
nics) by the BIOS consistently and BIOS guarantees it across every
reboot. If the OS also found and named the network ports in the same
manner, then there is no issue as integrated NIC port 1, designated Gb1
on the chassis, is always named as "eth0". But the observation is that,
it is not the case always.

-[0000:00]-+-00.0  Intel Corporation 5520 I/O Hub to ESI Port
           +-01.0-[0000:01]--+-00.0  Broadcom Corporation NetXtreme II
BCM5709 Gigabit Ethernet
           |                 \-00.1  Broadcom Corporation NetXtreme II
BCM5709 Gigabit Ethernet
           +-03.0-[0000:02]--+-00.0  Broadcom Corporation NetXtreme II
BCM5709 Gigabit Ethernet
           |                 \-00.1  Broadcom Corporation NetXtreme II
BCM5709 Gigabit Ethernet
           +-04.0-[0000:03]----00.0  LSI Logic / Symbios Logic MegaRAID
SAS 1078
           +-05.0-[0000:04]--
           +-06.0-[0000:05]--
           +-07.0-[0000:06]--
           +-09.0-[0000:07]----00.0  Intel Corporation 82598EB
10-Gigabit AT Network Connection

In such cases, pathnames like Embedded_NIC_1 -> eth[01..], point to the
right interface, and communicate a more meaningful name without any
state embedded in them.

With regards,
Narendra K

Download attachment "PER710-lspci-tv.output" of type "application/octet-stream" (735 bytes)