From: Greg KH <greg@kroah.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Matt Domsch <Matt_Domsch@dell.com>,
Narendra_K@dell.com, netdev@vger.kernel.org,
linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
Jordan_Hargrave@dell.com, Vijay_Nijhawan@dell.com,
Charles_Rose@dell.com
Subject: Re: [PATCH V2] Use firmware provided index to register a network
Date: Thu, 07 Oct 2010 17:15:32 +0000 [thread overview]
Message-ID: <20101007171532.GA29857@kroah.com> (raw)
In-Reply-To: <AANLkTinP5WPDPvk+kq8vsyP=xC9qcoe+c=1EBp0XJNPk@mail.gmail.com>
On Thu, Oct 07, 2010 at 07:05:14PM +0200, Kay Sievers wrote:
> On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> > On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> >> 1) SMBIOS type 41 method. Windows does not use this today, and I
> >> can't speak to their future plans. Narendra's kernel patch does,
> >> as has biosdevname, the udev helper we first wrote for this
> >> purpose, for several years.
> >
> > Then stick with that udev helper please :)
>
> What about just exporting this information in sysfs, and not touch the naming?
I think this is now exported in userspace, right Narendra?
> Anyway, I'm pretty sure all of this naming of onboard devices should
> happen only at install time, or from a system management tool and not
> at hotplug time.
>
> We should not get confused by the way the (very simple)
> automatic-rule-creater for persistent netdev naming in udev works.
> This is really just a tool for the common case, and works fine for the
> majority of people.
>
> I'm not sure, if we should put all these special use cases in the
> hotplug path. I mean it's not that people add and remove 4 port
> network cards with special BIOS all the time, and expect proper naming
> on the first bootup, right? The installer, or the system management
> tool could just create/edit udev rules to provide proper device naming
> on whatever property is available at a specific hardware, be it the
> MAC address or some other persistent match?
I totally agree.
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Matt Domsch <Matt_Domsch@dell.com>,
Narendra_K@dell.com, netdev@vger.kernel.org,
linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
Jordan_Hargrave@dell.com, Vijay_Nijhawan@dell.com,
Charles_Rose@dell.com
Subject: Re: [PATCH V2] Use firmware provided index to register a network interface
Date: Thu, 7 Oct 2010 10:15:32 -0700 [thread overview]
Message-ID: <20101007171532.GA29857@kroah.com> (raw)
In-Reply-To: <AANLkTinP5WPDPvk+kq8vsyP=xC9qcoe+c=1EBp0XJNPk@mail.gmail.com>
On Thu, Oct 07, 2010 at 07:05:14PM +0200, Kay Sievers wrote:
> On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> > On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> >> 1) SMBIOS type 41 method. Windows does not use this today, and I
> >> can't speak to their future plans. Narendra's kernel patch does,
> >> as has biosdevname, the udev helper we first wrote for this
> >> purpose, for several years.
> >
> > Then stick with that udev helper please :)
>
> What about just exporting this information in sysfs, and not touch the naming?
I think this is now exported in userspace, right Narendra?
> Anyway, I'm pretty sure all of this naming of onboard devices should
> happen only at install time, or from a system management tool and not
> at hotplug time.
>
> We should not get confused by the way the (very simple)
> automatic-rule-creater for persistent netdev naming in udev works.
> This is really just a tool for the common case, and works fine for the
> majority of people.
>
> I'm not sure, if we should put all these special use cases in the
> hotplug path. I mean it's not that people add and remove 4 port
> network cards with special BIOS all the time, and expect proper naming
> on the first bootup, right? The installer, or the system management
> tool could just create/edit udev rules to provide proper device naming
> on whatever property is available at a specific hardware, be it the
> MAC address or some other persistent match?
I totally agree.
thanks,
greg k-h
next prev parent reply other threads:[~2010-10-07 17:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-07 14:23 [PATCH V2] Use firmware provided index to register a network Narendra_K
2010-10-07 14:23 ` [PATCH V2] Use firmware provided index to register a network interface Narendra_K
2010-10-07 15:11 ` [PATCH V2] Use firmware provided index to register a network Greg KH
2010-10-07 15:11 ` [PATCH V2] Use firmware provided index to register a network interface Greg KH
2010-10-07 16:31 ` Matt Domsch
2010-10-07 16:31 ` Matt Domsch
2010-10-07 16:48 ` [PATCH V2] Use firmware provided index to register a network Greg KH
2010-10-07 16:48 ` [PATCH V2] Use firmware provided index to register a network interface Greg KH
2010-10-07 17:05 ` Kay Sievers
2010-10-07 17:05 ` Kay Sievers
2010-10-07 17:15 ` Greg KH [this message]
2010-10-07 17:15 ` Greg KH
2010-10-07 17:44 ` Narendra_K
2010-10-07 17:56 ` [PATCH V2] Use firmware provided index to register a network Narendra_K
2010-10-07 18:44 ` Narendra_K
2010-10-07 18:44 ` [PATCH V2] Use firmware provided index to register a network interface Narendra_K
2010-10-07 20:42 ` [PATCH V2] Use firmware provided index to register a network Matt Domsch
2010-10-07 20:42 ` [PATCH V2] Use firmware provided index to register a network interface Matt Domsch
2010-10-07 16:49 ` [PATCH V2] Use firmware provided index to register a network David Lamparter
2010-10-07 16:49 ` [PATCH V2] Use firmware provided index to register a network interface David Lamparter
2010-10-07 17:13 ` Kay Sievers
2010-10-07 17:13 ` Kay Sievers
2010-10-07 16:14 ` [PATCH V2] Use firmware provided index to register a network Stephen Hemminger
2010-10-07 16:14 ` [PATCH V2] Use firmware provided index to register a network interface Stephen Hemminger
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=20101007171532.GA29857@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=kay.sievers@vrfy.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.