| Message ID | 20101103165505.GA3281@fedora-14-r710.oslab.blr.amer.dell.com |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
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. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Nov 03, Greg KH <greg@kroah.com> wrote: > 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. Agreed. What about instructing users/installers to add something like this in /etc/udev/rules.d/00-something.rules? KERNEL=="eth*", ENV{UDEVLOM}="1" (Maybe with a more descriptive name than "UDEVLOM".)
> (Maybe with a more descriptive name than "UDEVLOM".) What is different from the already used Name? > > -- > ciao, > Marco > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAkzRqs8ACgkQFGfw2OHuP7EYEACZAeDc/phuXkT89y+bGtsYROYN > Pw0An1Lti6pAyXjt/pjIj8L9h7V5hXTC > =Keaz > -----END PGP SIGNATURE----- > >
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
> At Linux Plumbers Conference today, this problem space was discussed > once again, and I believe concensus on approach was reached. Here > goes: Was the patch a starting point for the discussion. > * 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. I would like to know what is the difference in the nomenclature for this. > > * 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. How will you manage these scenarios. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 08, 2010 at 02:12:56PM +0530, Sujit K M wrote: > > At Linux Plumbers Conference today, this problem space was discussed > > once again, and I believe concensus on approach was reached. ?Here > > goes: > > Was the patch a starting point for the discussion. The discussion has been ongoing for 3 years. This patch was posted just prior to the conversation at LPC, where aspects of this patch (reading values from sysfs and using them, if present) were discussed at length. The patch itself will have to undergo some changes based on the outcome of that discussion. > > * 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. > > I would like to know what is the difference in the nomenclature for this. LOM == "LAN on Motherboard", aka "Embedded NIC". I'm not wedded to using "lomX", but it can't be ethX, and it must be short, and that's as good as anything. > > * 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. > > How will you manage these scenarios. I've had conversations with the relevant maintainers of the subsystems of each of the major distributions. What else are you looking for please? Thanks, Matt
On 11/03/2010 05:55 PM, 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'. > > From: Narendra K<narendra_k@dell.com> > Subject: [PATCH] UDEV - Add 'udevlom' command line param to start_udev > > This patch implements 'udevlom' command line parameter, which > when passed, results in onboard network interfaces getting > renamed to lomN. > > Signed-off-by: Narendra K<narendra_k@dell.com> > --- > start_udev | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/start_udev b/start_udev > index 49fc286..57d60c9 100755 > --- a/start_udev > +++ b/start_udev > @@ -32,6 +32,7 @@ export TZ=/etc/localtime > . /etc/init.d/functions > > prog=udev > +cmdline=`cat /proc/cmdline` > > touch_recursive() { > ( cd $1; > @@ -60,6 +61,10 @@ fi > > ret=$[$ret + $?] > > +if strstr "$cmdline" udevlom; then > + /sbin/udevadm control --env=UDEVLOM="y" > +fi > + > /sbin/udevadm trigger --type=subsystems --action=add > /sbin/udevadm trigger --type=devices --action=add > /sbin/udevadm settle start_udev is obsolete with the use of systemd service files anyway in Fedora>=15 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/10/2010 05:32 PM, Harald Hoyer wrote: > On 11/03/2010 05:55 PM, 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'. >> >> From: Narendra K<narendra_k@dell.com> >> Subject: [PATCH] UDEV - Add 'udevlom' command line param to start_udev >> >> This patch implements 'udevlom' command line parameter, which >> when passed, results in onboard network interfaces getting >> renamed to lomN. >> >> Signed-off-by: Narendra K<narendra_k@dell.com> >> --- >> start_udev | 5 +++++ >> 1 files changed, 5 insertions(+), 0 deletions(-) >> >> diff --git a/start_udev b/start_udev >> index 49fc286..57d60c9 100755 >> --- a/start_udev >> +++ b/start_udev >> @@ -32,6 +32,7 @@ export TZ=/etc/localtime >> . /etc/init.d/functions >> >> prog=udev >> +cmdline=`cat /proc/cmdline` >> >> touch_recursive() { >> ( cd $1; >> @@ -60,6 +61,10 @@ fi >> >> ret=$[$ret + $?] >> >> +if strstr "$cmdline" udevlom; then >> + /sbin/udevadm control --env=UDEVLOM="y" >> +fi >> + >> /sbin/udevadm trigger --type=subsystems --action=add >> /sbin/udevadm trigger --type=devices --action=add >> /sbin/udevadm settle > > start_udev is obsolete with the use of systemd service files anyway in Fedora>=15 not saying that we really should use "udevlom" on the kernel command line, but you could use: IMPORT{cmdline}="udevlom" KERNEL="eth*", ENV{udevlom}==1, .... -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 04, 2010 at 09:58:48PM -0500, Matt Domsch wrote: > 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) I'm getting a lot of pushback from Dell customers on our linux-poweredge mailing list (thread starts [1]) that the choice of name "lomX" is poor, due to HP's extensive use of LOM meaning Lights Out Management, rather than my intended meaning of "LAN on Motherboard". Gotta hate TLA collisions. So, I'm open to new ideas for naming these. At LPC, Ted noted that 2- and 3-letter names are expected. "nic[1234]" or "en[1234]" ? And yes, they'd prefer that we keep "eth[0123]" for the onboard devices, but I simply don't see how to do that without kernel changes, due to the races in both naming them in the kernel vs udev renaming, and simple races between two udev processes. Thanks, Matt [1] http://lists.us.dell.com/pipermail/linux-poweredge/2010-November/043576.html
On Mon, 2010-11-15 at 10:47 -0600, Matt Domsch wrote: > On Thu, Nov 04, 2010 at 09:58:48PM -0500, Matt Domsch wrote: > > 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) > > I'm getting a lot of pushback from Dell customers on our > linux-poweredge mailing list (thread starts [1]) that the choice of > name "lomX" is poor, due to HP's extensive use of LOM meaning Lights > Out Management, rather than my intended meaning of "LAN on > Motherboard". Gotta hate TLA collisions. > > So, I'm open to new ideas for naming these. At LPC, Ted noted that > 2- and 3-letter names are expected. "nic[1234]" or "en[1234]" ? [...] I would suggest avoiding "nic" since some people use "NIC" to mean specifically an add-in card rather than LOM. In addition there is some ambiguity with multi-port cards/controllers of whether NIC means a controller or a port. Other options for the prefix: - "lan". Maybe too generic. - "mbe" = MotherBoard Ethernet. Looks a bit like "GbE" as some OEMs put on the port labels. - "eom" = Ethernet On Motherboard Ben.
>>I'm getting a lot of pushback from Dell customers on our >>linux-poweredge mailing list (thread starts [1]) that the choice of >>name "lomX" is poor, due to HP's extensive use of LOM meaning Lights >>Out Management, rather than my intended meaning of "LAN on >>Motherboard". Gotta hate TLA collisions. I think Sun (sorry, Oracle) push LOM for Lights-Out Management quite a lot - calling their service processor an iLOM IIRC. >>So, I'm open to new ideas for naming these. At LPC, Ted noted that >>2- and 3-letter names are expected. "nic[1234]" or "en[1234]" ? > > [...] > > I would suggest avoiding "nic" since some people use "NIC" to mean > specifically an add-in card rather than LOM. In addition there is some > ambiguity with multi-port cards/controllers of whether NIC means a > controller or a port. > > Other options for the prefix: > - "lan". Maybe too generic. yes and no - that is the prefix for "ethernet" network interface names in HP-UX, going back decades. so, there is precedent for that, and given the way HP-UX device name persistence works, 99 times out of ten, the "built-in" or "core" LAN interfaces ended-up being enumerated starting from zero - lan0, lan1, etc. (There are exceptions relating to certain modles of systems and a full re-install of the OS with add-on cards present but that is a story for another thread). > - "mbe" = MotherBoard Ethernet. Looks a bit like "GbE" as some OEMs put > on the port labels. Collides with Multi-Bit Error. > - "eom" = Ethernet On Motherboard Collides with End of Message. If there is indeed *no* way to get then named eth[1-N], and "lan" doesn't resonate well-enough, then my contribution to the bikeshed would be "cor" simply because I don't know the TLA with which that collides :) Are folks sufficently confident that using anything other than "eth" won't cause some unpleasant "our app always ass-u-me-d interfaces started with 'eth'" situations? rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > - "mbe" = MotherBoard Ethernet. Looks a bit like "GbE" as some OEMs put > > on the port labels. > > Collides with Multi-Bit Error. > > > - "eom" = Ethernet On Motherboard > > Collides with End of Message. > On board ethernet(obe)? On board nic(obn)? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Are folks sufficently confident that using anything other than "eth" > won't cause some unpleasant "our app always ass-u-me-d interfaces started with > 'eth'" situations? > Good point. I'm sure folks use 'eth' in their regex filters. Please ignore my obe/obn email. > rick jones Chetan Loke -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 24 Nov 2010, Loke, Chetan wrote: > > Are folks sufficently confident that using anything other than "eth" > > won't cause some unpleasant "our app always ass-u-me-d interfaces > started with > > 'eth'" situations? > > Good point. I'm sure folks use 'eth' in their regex filters. Please > ignore my obe/obn email. If the 2 or 3 character name isn't a hard requirement, then ethm for eth(ernet on )m(otherboard) would seem a natural possibility. -Bill -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 24, 2010 at 09:56:08PM -0500, Bill Fink wrote: > On Wed, 24 Nov 2010, Loke, Chetan wrote: > > > > Are folks sufficently confident that using anything other than "eth" > > > won't cause some unpleasant "our app always ass-u-me-d interfaces > > started with > > > 'eth'" situations? > > > > Good point. I'm sure folks use 'eth' in their regex filters. Please > > ignore my obe/obn email. > > If the 2 or 3 character name isn't a hard requirement, then > ethm for eth(ernet on )m(otherboard) would seem a natural > possibility. I went with 'em' (embedded or ethernet-on-motherboard) in biosdevname. Git tree at: http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=biosdevname.git;a=summary Now I'm just trying to figure out why it seems pciutils libpci is unhappy when the device tree is constantly changing underneath it, such as when loading ixgbe max_vfs=63 - each new SR-IOV device created launches a new udev instance as expected, but the device tree as seen from any one of them may not be quite right as it's changing... Thanks, Matt
diff --git a/start_udev b/start_udev index 49fc286..57d60c9 100755 --- a/start_udev +++ b/start_udev @@ -32,6 +32,7 @@ export TZ=/etc/localtime . /etc/init.d/functions prog=udev +cmdline=`cat /proc/cmdline` touch_recursive() { ( cd $1; @@ -60,6 +61,10 @@ fi ret=$[$ret + $?] +if strstr "$cmdline" udevlom; then + /sbin/udevadm control --env=UDEVLOM="y" +fi + /sbin/udevadm trigger --type=subsystems --action=add /sbin/udevadm trigger --type=devices --action=add /sbin/udevadm settle