From: Matt Domsch <Matt_Domsch@Dell.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: Narendra_K@Dell.com, netdev@vger.kernel.org,
Charles_Rose@Dell.com, Jordan_Hargrave@Dell.com,
linux-pci@vger.kernel.org, linux-hotplug@vger.kernel.org
Subject: Re: [PATCH] Add firmware label support to iproute2
Date: Thu, 26 Aug 2010 15:01:16 +0000 [thread overview]
Message-ID: <20100826150116.GB21770@auslistsprd01.us.dell.com> (raw)
In-Reply-To: <20100825171646.3d40b721@nehalam>
On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> On Wed, 25 Aug 2010 17:03:23 -0500
On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> Is it really a good idea to have to change every utility that could
> alter network devices? There is iproute2, iputils, tcpdump, wireshark,
> quagga, snmp, ... Many of the utilities come from a BSD world,
> and will be less likely to accept some Linux specific wart.
I agree, I don't want to have to change all those userspace apps
either. We've started creating patches and are willing to do so if it
will yield the result we want though.
> I have lost faith in this library wrapper support everywhere method.
> Let's just keep the firmware stuff in udev. If the user wants to
> have a policy that renames device from eth0 to "Embedded BIOS LAN1" then
> do it in udev. Or if you want to keep the ethX naming convention
> and stuff the firmware label into ifAlias or other sysfs field
> so it can be displayed that will be not a big issue.
1) we remain constrained to IFNAMSIZ named arguments. There is no
such constraint on BIOS-provided names. Dell BIOS presently uses
'Embedded NIC 1' which (fortunately) is 14 chars. We're cutting it
awfully close already. I can't dictate to non-Dell BIOS vendors
what to use as their strings, or how long to make them.
digression 1a) udev has a replace-spaces-with-underscores feature I used in
the biosdevname udev rules. That's a reasonable munging of the
provided strings. Much more than that and I'm not sure we could
consistently get it right.
2) there are apps which use a regexp for device names. We'd have to
find and fix those too. Arguably we'd have to do this when we
patch them to use libnetdevname. [1]
3) it continues to force a single naming convention for NICs, where
for other types of devices we can have several independent naming
conventions. I have end users who wish to name their interfaces by
the BIOS label, others by the function (public, dmz,
backup, storage, ...) that the network segment provides. While we
could have different policies, each system can have only one policy
at a time.
David Miller had suggested [2] that we could add a method to get
alternate labels for devices by querying them. We've got something
similar now by exporting the labels for devices in sysfs. Yea -
progress!
But we can't _use_ those labels for more than display
(meaning a human is doing the mapping in their heads), or to rename
devices. We can't use the labels in scripts without doing the label->kernel
name lookups, and then using the kernel name.
I'm open to revisiting the "have udev rename devices", but I tried
that with biosdevname 2 years ago, with little success. Adding in the
hotplug dev team to the thread.
[1] http://marc.info/?l=linux-netdev&m\x125522163322610&w=2 (Marco d'Itri)
[2] http://marc.info/?l=linux-hotplug&m\x123793549323431&w=2
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
next parent reply other threads:[~2010-08-26 15:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100812173537.GA29784@auslistsprd01.us.dell.com>
[not found] ` <20100812141240.417949e2@s6510>
[not found] ` <EDA0A4495861324DA2618B4C45DCB3EE612E34@blrx3m08.blr.amer.dell.com>
[not found] ` <20100818144124.33a72453@nehalam>
[not found] ` <20100819213314.GA26135@auslistsprd01.us.dell.com>
[not found] ` <20100819145308.0fa08522@nehalam>
[not found] ` <20100825220323.GA12671@auslistsprd01.us.dell.com>
[not found] ` <20100825171646.3d40b721@nehalam>
2010-08-26 15:01 ` Matt Domsch [this message]
2010-08-26 15:17 ` [PATCH] Add firmware label support to iproute2 Loke, Chetan
2010-08-26 15:21 ` Stephen Hemminger
2010-08-26 15:38 ` Loke, Chetan
2010-08-27 7:54 ` Kay Sievers
2010-08-26 16:38 ` Matt Domsch
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=20100826150116.GB21770@auslistsprd01.us.dell.com \
--to=matt_domsch@dell.com \
--cc=Charles_Rose@Dell.com \
--cc=Jordan_Hargrave@Dell.com \
--cc=Narendra_K@Dell.com \
--cc=linux-hotplug@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.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).