From: Greg KH <greg@kroah.com>
To: Narendra_K@Dell.com
Cc: netdev@vger.kernel.org, linux-hotplug@vger.kernel.org,
linux-pci@vger.kernel.org, Matt_Domsch@Dell.com,
Charles_Rose@Dell.com, Jordan_Hargrave@Dell.com,
Vijay_Nijhawan@Dell.com
Subject: Re: [PATCH] Use firmware provided index to register a network
Date: Thu, 07 Oct 2010 14:31:58 +0000 [thread overview]
Message-ID: <20101007143158.GA14913@kroah.com> (raw)
In-Reply-To: <20101007141433.GA2641@libnet-test.oslab.blr.amer.dell.com>
On Thu, Oct 07, 2010 at 07:44:57PM +0530, Narendra_K@Dell.com wrote:
> On Thu, Sep 23, 2010 at 10:03:36PM +0530, Greg KH wrote:
> > On Thu, Sep 23, 2010 at 09:20:57PM +0530, Narendra_K@Dell.com wrote:
> > > > Now trying to change the kernel namespace itself seems like a bad hack
> > > > around this fact.
> > > >
> > >
> > > The patch does not change the existing kernel name space.
> >
> > You are "reordering it", right?
> >
> > > It adheres to the existing ethN name space with IFNAMSIZ length
> > > requirements. The patch only makes sure that eth0 always corresponds
> > > to what is labeled as 'Gb1' on server chassis, on systems where SMBIOS
> > > type 41 record is available. And removes the need for any renames for
> > > the interfaces which have a firmware index assigned by system
> > > firmware, as the very first name assigned by the kernel will be as
> > > expected and deterministic.
> >
> > And on systems with buggy firmware, what is going to happen here? And
> > yes, there will be buggy BIOS tables, we can guarantee that, as this is
> > not something that Windows supports, right?
> >
>
> It took some time to find out the details asked above. Right, windows
> does not use SMBIOS type 41 record to derive names. But as a datapoint,
> windows also has the same problem.
If windows does not use this field, then you can guarantee it will show
up incorrectly in BIOSes and never be tested by manufacturers before
they ship their machines.
> Yes, firmware and BIOS tables can be buggy. How about a command line
> parameter 'no_netfwindex', passing which firmware index will not be
> used to derive ethN names ? That would handle the scenario of buggy
> firmware and names will be derived in the now existing way.
I'd prefer the option never be added in the first place as you are
placing a big burden on people whose machines were working properly on
old kernels, to suddenly have to add a command line option to get their
box to now work again.
And again, as this is a "simple" rename type operation, I still don't
see why you can't just do this from a udev rule, especially if the
firmware information is exported to userspace. That is where such
"policy" should be added, not within the kernel itself.
thanks,
greg k-h
next prev parent reply other threads:[~2010-10-07 14:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-22 18:31 [PATCH] Use firmware provided index to register a network interface Narendra K
2010-09-22 19:22 ` [PATCH] Use firmware provided index to register a network Greg KH
2010-09-23 15:22 ` [PATCH] Use firmware provided index to register a network interface Narendra_K
2010-09-23 15:27 ` [PATCH] Use firmware provided index to register a network Greg KH
2010-09-23 15:51 ` [PATCH] Use firmware provided index to register a network interface Narendra_K
2010-09-23 16:33 ` [PATCH] Use firmware provided index to register a network Greg KH
2010-10-07 14:26 ` Narendra_K
2010-10-07 14:27 ` [PATCH] Use firmware provided index to register a network interface Tim Small
2010-10-07 14:31 ` Greg KH [this message]
2010-09-22 22:07 ` Tim Small
2010-09-22 22:16 ` [PATCH] Use firmware provided index to register a network Stephen Hemminger
2010-09-23 6:34 ` [PATCH] Use firmware provided index to register a network interface Tim Small
2010-09-23 15:25 ` Narendra_K
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=20101007143158.GA14913@kroah.com \
--to=greg@kroah.com \
--cc=Charles_Rose@Dell.com \
--cc=Jordan_Hargrave@Dell.com \
--cc=Matt_Domsch@Dell.com \
--cc=Narendra_K@Dell.com \
--cc=Vijay_Nijhawan@Dell.com \
--cc=linux-hotplug@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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).