netdev - Re: Network Device Naming mechanism and policy

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:	Tue, 24 Mar 2009 15:57:56 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	Matt_Domsch@...l.com
Cc:	netdev@...r.kernel.org, linux-hotplug@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Network Device Naming mechanism and policy

From: Matt Domsch <Matt_Domsch@...l.com>
Date: Tue, 24 Mar 2009 10:46:17 -0500

> Problem: Users expect on-motherboard NICs to be named eth0..ethN.
> This can be difficult to achieve.

I learned a long time ago that eth0 et al. have zero meaning.

If the system firmware folks gave us topology information with respect
to these things, we could export something that tools such as
NetworkManager, iproute2, etc. could use.

For example, if we were told that PCI device "domain:bus:dev:fn" has
string label "Onboard Ethernet 0" then we could present that to the
user.

Changing how the actual network device name is determined is going to
have zero traction.

So, please, put mapping tables into the ACPI or similar and then
programs can go:

	for_each_network_device(name) {
		fd = open(name);
		label = get_system_label(fd, name);
		present_to_user(label, name);
	}

This "get_system_label()" thing can be an ethtool ioctl, some
rtnetlink call, or similar.  In the kernel, a generic routine would
exist for major bus types to make the mapping translation, and drivers
would call these.

For PCI it might take the PCI device pointer and try to fish
out a string from the ACPI layer.

For OpenFirmware we might just simply give the full device path,
or a matching device alias name.

That's the only model which allows a smooth transition and
no major infrastructure changes.

I guess it's easier to spew about MAC addresses and other
irrelevant topics than try to solve this problem properly. :-)
--
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