netdev - Re: network interface *name* alias support?

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]

Date:	Fri, 23 May 2008 15:06:43 -0400
From:	Jon Masters <jonathan@...masters.org>
To:	Rick Jones <rick.jones2@...com>
Cc:	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	Jan Engelhardt <jengelh@...ozas.de>, johnathan@...masters.org,
	netdev@...r.kernel.org, dwmw2@...radead.org
Subject: Re: network interface *name* alias support?

On Fri, 2008-05-23 at 10:44 -0700, Rick Jones wrote:
> > FWIW you can just use ethtool to determine the slot address quickly
> > in userspace. There's no real need to do this in the kernel.
> > 
> > # ethtool -i eth0
> > driver: e1000e
> > version: 0.2.0
> > firmware-version: 1.3-0
> > bus-info: 0000:00:19.0
> 
> And if it happens to be in a hotplug slot today with a suitable hotplug 
> module (term?) loaded like acpiphp you can then map that to a more human 
> friendly slot number/name.  In the future, once Alex Chiang's pci slots 
> patches make it to mainline it will be possible even with non-hotplug slots.

Yep, that's all great until the bus topology changes underneath you.
There is a need for alias support, because it will allow distributions
to assign a name based upon the *slot ordering specified by the vendor*
and therefore allow a consistent slot number no matter what hotplug
happens, what devices are added or removed, which devices are on-board
vs. in cards, and even (eventually) for non-PCI cards.

In the case of Fedora, right now, we have files:

ifcfg-eth<whatever>

These bind to an interface based on the MAC address. If you swap out the
card, you lose. If you pull out the disks from the machine and put them
into another similar machine, you lose. If you put the disks from the
machine into a less similar machine, but one that still has multiple
network interfaces, you lose.

Some enterprise distributions actually have to play with "bfsort" PCI
enumeration orderings in order to ensure that network devices come up in
a reliable order...this is not the way to be (in the longer term)
determining what order the vendor thinks those cards should be in. This
is why they have a DMI extension that allows them to specify this
without being concerned with PCI bus orderings, or anything else.

My intention is to also allow for:

ifcfg-slot_<whatever>

Where the configuration is based entirely upon what vendor <XYZ> says is
the first, second, or third card. Then, those who want to use the older
names can continue to do so, but those who prefer to base their
configuration upon the order the vendor states, can do so.

Jon.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html