All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Domsch <Matt_Domsch@Dell.com>
To: Greg KH <greg@kroah.com>
Cc: "K, Narendra" <Narendra_K@Dell.com>,
	"linux-hotplug@vger.kernel.org" <linux-hotplug@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"Hargrave, Jordan" <Jordan_Hargrave@Dell.com>,
	"Rose, Charles" <Charles_Rose@Dell.com>
Subject: Re: [PATCH 1/1] UDEV - Add 'udevlom' command line param to start_udev
Date: Fri, 05 Nov 2010 02:58:48 +0000	[thread overview]
Message-ID: <20101105025848.GA14021@pws490.domsch.com> (raw)
In-Reply-To: <20101103180500.GA7441@kroah.com>

On Wed, Nov 03, 2010 at 11:05:00AM -0700, Greg KH wrote:
> On Wed, Nov 03, 2010 at 10:25:25PM +0530, Narendra_K@Dell.com wrote:
> > Hello,
> > 
> > This patch allows users to specify if they want the onboard network
> > interfaces to be renamed to lomN by implementing a command line param
> > 'udevlom'.
> 
> Ick ick ick.
> 
> Why not do this in some other configuration file?  Don't rely on udev
> being started with a different option, that is only ripe for abuse by
> everyone else who wants their pet-project to get into the udev
> environment.
> 
> Please, surely there's a different way to do this.

At Linux Plumbers Conference today, this problem space was discussed
once again, and I believe concensus on approach was reached.  Here
goes:

* If a 70-persistent-net.rules file sets a name, honor that.  This
  preserves existing installs.

* If BIOS provides indexes for onboard devices, honor that.
** Rename onboard NICs "lom[1-N]" as BIOS reports (# matches chassis labels)
** No rename for all others "ethX" (no change for NICs in PCI slots/USB/others)

* If neither are true, do not rename at all.

* Implementation will be:
** Udev rules to be included in upstream udev will read the index
   value from sysfs (provided by SMBIOS 2.6 info on kernels >= 2.6.36,
   PCI DSM info at some future point) if present, and rename LOMs
   based on that index value.  Distros will use these rules by default
   (Ubuntu and Fedora maintainers on board with the concept; I have
   not spoken with other distros yet.)
** Legacy distros with older udev rules will invoke biosdevname on
   kernels < 2.6.36 to get the same information, if present, and will
   rename LOMs based on index value.

** Installers will use the above udev rules by default.  If there is
   outcry during the distros beta testing periods, a way to disable
   these renames may be implemented.

* NetworkManager to display BIOS-provided labels as informational text


As such, biosdevname will be packaged and included in Debian and
Ubuntu (thanks to Colin Watson) to facilitate use in the udev rules.
Colin also suggested that any string used in Fedora kickstart files to
enable/disable this feature will also be used to enable/disable this
feature in the Debian & Ubuntu installers.  Given today's discussion
that the feature be enabled by default, this flag, if needed at all,
will be to disable the feature.

Does this seem sane to everyone?  Next step is to integrate
biosdevname into udev rules in a sane manner.

Thanks,
Matt

-- 
Matt Domsch
Technology Strategist, Dell Office of the CTO

WARNING: multiple messages have this Message-ID (diff)
From: Matt Domsch <Matt_Domsch@Dell.com>
To: Greg KH <greg@kroah.com>
Cc: "K, Narendra" <Narendra_K@Dell.com>,
	"linux-hotplug@vger.kernel.org" <linux-hotplug@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"Hargrave, Jordan" <Jordan_Hargrave@Dell.com>,
	"Rose, Charles" <Charles_Rose@Dell.com>
Subject: Re: [PATCH 1/1] UDEV - Add 'udevlom' command line param to start_udev
Date: Thu, 4 Nov 2010 21:58:48 -0500	[thread overview]
Message-ID: <20101105025848.GA14021@pws490.domsch.com> (raw)
In-Reply-To: <20101103180500.GA7441@kroah.com>

On Wed, Nov 03, 2010 at 11:05:00AM -0700, Greg KH wrote:
> On Wed, Nov 03, 2010 at 10:25:25PM +0530, Narendra_K@Dell.com wrote:
> > Hello,
> > 
> > This patch allows users to specify if they want the onboard network
> > interfaces to be renamed to lomN by implementing a command line param
> > 'udevlom'.
> 
> Ick ick ick.
> 
> Why not do this in some other configuration file?  Don't rely on udev
> being started with a different option, that is only ripe for abuse by
> everyone else who wants their pet-project to get into the udev
> environment.
> 
> Please, surely there's a different way to do this.

At Linux Plumbers Conference today, this problem space was discussed
once again, and I believe concensus on approach was reached.  Here
goes:

* If a 70-persistent-net.rules file sets a name, honor that.  This
  preserves existing installs.

* If BIOS provides indexes for onboard devices, honor that.
** Rename onboard NICs "lom[1-N]" as BIOS reports (# matches chassis labels)
** No rename for all others "ethX" (no change for NICs in PCI slots/USB/others)

* If neither are true, do not rename at all.

* Implementation will be:
** Udev rules to be included in upstream udev will read the index
   value from sysfs (provided by SMBIOS 2.6 info on kernels >= 2.6.36,
   PCI DSM info at some future point) if present, and rename LOMs
   based on that index value.  Distros will use these rules by default
   (Ubuntu and Fedora maintainers on board with the concept; I have
   not spoken with other distros yet.)
** Legacy distros with older udev rules will invoke biosdevname on
   kernels < 2.6.36 to get the same information, if present, and will
   rename LOMs based on index value.

** Installers will use the above udev rules by default.  If there is
   outcry during the distros beta testing periods, a way to disable
   these renames may be implemented.

* NetworkManager to display BIOS-provided labels as informational text


As such, biosdevname will be packaged and included in Debian and
Ubuntu (thanks to Colin Watson) to facilitate use in the udev rules.
Colin also suggested that any string used in Fedora kickstart files to
enable/disable this feature will also be used to enable/disable this
feature in the Debian & Ubuntu installers.  Given today's discussion
that the feature be enabled by default, this flag, if needed at all,
will be to disable the feature.

Does this seem sane to everyone?  Next step is to integrate
biosdevname into udev rules in a sane manner.

Thanks,
Matt

-- 
Matt Domsch
Technology Strategist, Dell Office of the CTO

  parent reply	other threads:[~2010-11-05  2:58 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-03 16:55 [PATCH 1/1] UDEV - Add 'udevlom' command line param to start_udev Narendra_K
2010-11-03 16:58 ` Narendra_K
2010-11-03 18:05 ` [PATCH 1/1] UDEV - Add 'udevlom' command line param to Greg KH
2010-11-03 18:05   ` [PATCH 1/1] UDEV - Add 'udevlom' command line param to start_udev Greg KH
2010-11-03 18:32   ` [PATCH 1/1] UDEV - Add 'udevlom' command line param to Marco d'Itri
2010-11-03 18:32     ` [PATCH 1/1] UDEV - Add 'udevlom' command line param to start_udev Marco d'Itri
2010-11-04  8:37     ` Sujit K M
2010-11-04  8:49       ` Sujit K M
2010-11-05  2:58   ` Matt Domsch [this message]
2010-11-05  2:58     ` Matt Domsch
2010-11-08  8:42     ` Sujit K M
2010-11-08  8:54       ` Sujit K M
2010-11-08 18:17       ` Matt Domsch
2010-11-08 18:17         ` Matt Domsch
2010-11-15 16:47     ` Matt Domsch
2010-11-15 16:47       ` Matt Domsch
2010-11-15 17:16       ` [PATCH 1/1] UDEV - Add 'udevlom' command line param to Ben Hutchings
2010-11-15 17:16         ` [PATCH 1/1] UDEV - Add 'udevlom' command line param to start_udev Ben Hutchings
2010-11-15 19:32         ` Rick Jones
2010-11-15 19:32           ` Rick Jones
2010-11-24 20:57           ` Loke, Chetan
2010-11-24 20:57             ` Loke, Chetan
2010-11-24 21:13           ` Loke, Chetan
2010-11-24 21:13             ` Loke, Chetan
2010-11-25  2:56             ` [PATCH 1/1] UDEV - Add 'udevlom' command line param to Bill Fink
2010-11-25  2:56               ` [PATCH 1/1] UDEV - Add 'udevlom' command line param to start_udev Bill Fink
2010-11-26  2:09               ` Matt Domsch
2010-11-26  2:09                 ` Matt Domsch
2010-11-10 16:32 ` Harald Hoyer
2010-11-10 16:32   ` Harald Hoyer
2010-11-10 16:37   ` Harald Hoyer
2010-11-10 16:37     ` Harald Hoyer

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=20101105025848.GA14021@pws490.domsch.com \
    --to=matt_domsch@dell.com \
    --cc=Charles_Rose@Dell.com \
    --cc=Jordan_Hargrave@Dell.com \
    --cc=Narendra_K@Dell.com \
    --cc=greg@kroah.com \
    --cc=linux-hotplug@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.