From: Narendra K <hidden> Date: 2009-10-12 18:47:12
On Mon, Oct 12, 2009 at 01:45:28PM -0400, Bill Nottingham wrote:
quoted
Greg KH (greg@kroah.com) said:
quoted
quoted
Today, port naming is completely nondeterministic. If you have
but one NIC, there are few chances to get the name wrong (it'll be
eth0).
quoted
quoted
quoted
If you have >1 NIC, chances increase to get it wrong.
That is why all distros name network devices based on the only
deterministic thing they have today, the MAC address. I still fail
to see why you do not like this solution, it is honestly the only
way to properly name network devices in a sane manner.
All distros also provide a way to easily rename the network devices,
quoted
quoted
to place a specific name on a specific MAC address, so again, this
should all be solved already.
No, it's not solved. Even if you have persistent names once you
install, if you ever re-image, you're likely to get *different*
persistent names; the first load will always be non-detmerministic.
The only way around this would be to have some sort of screen like:
Would you like your network devices to be enumerated by
[ ] MAC address
[ ] PCI device order
[ ] Driver name
[ ] Other
[ ] PCI slot name
That's one that modern systems are now reporting, and should solve
Matt's problem as well, right?
MAC address and pci slots might ensure that device names are persistant
across system reboots. They do not assure that the LOM 1 is named as
"eth0" which is the expectation. In case of unattended installs,
installers abort installation if the port which gets the name "eth0"
does not have the link up and doesn't have the IP.This is often the case
becaused the LOMS have the boot capability. We can acheive
persistent naming using MAC adresses. But it doesn't address the
expectation that LOM-1 becomes "eth0" on every reboot which is mostly
used for unattended installs.(Installers can be told to use options like
IPAPPEND 2, but the this solution would make it of no use).
quoted
which is just all sorts of fail in and of itself. Especially since
once you get to the point where you can coherently ask this in a
native installer, the drivers have already loaded.
No, the driver load order doesn't determine this, you need the drivers
loaded first before you can rename anything :)
Renaming an interface in the kernel namespace itself, might need to
problems like duplicate names. But having names in alternate namespace not in kernel
namespace might be more useful.
And I don't see how Matt's proposed patch helps resolve this type of
issue any better than what we currently have today, do you?
I have a system which has 4 LOMS and 1 add-in NIC and the add-in NIC
always gets the name "eth0" eventhough i PXE booted from LOM-1. Since
"eth0" doesn't have link up, the installer stops and asks which
interface should get IP. This would not suit an unattended install
scenario. If the installer can use a pathname like
/dev/net/by-chassis-label/Embedded_NIC_1 (->eth1 which is my LOM-1), it
would always point to the correct interface irrespective of whether it
is "eth0" or not.
With regards,
Narendra K
On Mon, Oct 12, 2009 at 01:47:12PM -0500, Narendra K wrote:
quoted
On Mon, Oct 12, 2009 at 01:45:28PM -0400, Bill Nottingham wrote:
quoted
Greg KH (greg@kroah.com) said:
quoted
quoted
Today, port naming is completely nondeterministic. If you have
but one NIC, there are few chances to get the name wrong (it'll be
eth0).
quoted
quoted
quoted
If you have >1 NIC, chances increase to get it wrong.
That is why all distros name network devices based on the only
deterministic thing they have today, the MAC address. I still fail
to see why you do not like this solution, it is honestly the only
way to properly name network devices in a sane manner.
All distros also provide a way to easily rename the network devices,
quoted
quoted
to place a specific name on a specific MAC address, so again, this
should all be solved already.
No, it's not solved. Even if you have persistent names once you
install, if you ever re-image, you're likely to get *different*
persistent names; the first load will always be non-detmerministic.
The only way around this would be to have some sort of screen like:
Would you like your network devices to be enumerated by
[ ] MAC address
[ ] PCI device order
[ ] Driver name
[ ] Other
[ ] PCI slot name
That's one that modern systems are now reporting, and should solve
Matt's problem as well, right?
MAC address and pci slots might ensure that device names are persistant
across system reboots. They do not assure that the LOM 1 is named as
"eth0" which is the expectation.
"LOM"?
Isn't what you want is a PCI slot detection, combined with the order on
board in which the port is enumerated?
In case of unattended installs, installers abort installation if the
port which gets the name "eth0" does not have the link up and doesn't
have the IP.
Sounds like a broken installer :)
This is often the case becaused the LOMS have the boot capability. We
can acheive persistent naming using MAC adresses. But it doesn't
address the expectation that LOM-1 becomes "eth0" on every reboot
which is mostly used for unattended installs.(Installers can be told
to use options like IPAPPEND 2, but the this solution would make it of
no use).
I still fail to see how this dummy char device would solve this problem,
as everything you can do today in userspace would be the same with this
device node as you can't do anything with the symlink name on its own,
right?
quoted
quoted
which is just all sorts of fail in and of itself. Especially since
once you get to the point where you can coherently ask this in a
native installer, the drivers have already loaded.
No, the driver load order doesn't determine this, you need the drivers
loaded first before you can rename anything :)
Renaming an interface in the kernel namespace itself, might need to
problems like duplicate names. But having names in alternate namespace
not in kernel namespace might be more useful.
Not if you can't do anything useful with those names :)
quoted
And I don't see how Matt's proposed patch helps resolve this type of
issue any better than what we currently have today, do you?
I have a system which has 4 LOMS and 1 add-in NIC and the add-in NIC
always gets the name "eth0" eventhough i PXE booted from LOM-1. Since
"eth0" doesn't have link up, the installer stops and asks which
interface should get IP. This would not suit an unattended install
scenario. If the installer can use a pathname like
/dev/net/by-chassis-label/Embedded_NIC_1 (->eth1 which is my LOM-1), it
would always point to the correct interface irrespective of whether it
is "eth0" or not.
Um, again, you can name your network devices like this today, without
these symlinks...
thanks,
greg k-h
From: Karl O. Pinc <hidden> Date: 2009-10-12 19:41:50
On 10/12/2009 02:09:00 PM, Greg KH wrote:
"LOM"?
"LAN On Motherboard" of all things.
(I had to look this
one up. The expansion better suited
to today's economy is "Low On Manna".)
Karl [off-list ref]
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
From: Matt Domsch <hidden> Date: 2009-10-12 19:49:14
On Mon, Oct 12, 2009 at 12:09:00PM -0700, Greg KH wrote:
"LOM"?
LAN on Motherboard (e.g. an embedded NIC, as opposed to being in some
slot).
Isn't what you want is a PCI slot detection, combined with the order on
board in which the port is enumerated?
Most folks do, yes.
I still fail to see how this dummy char device would solve this problem,
as everything you can do today in userspace would be the same with this
device node as you can't do anything with the symlink name on its own,
right?
You are correct, the char device by itself doesn't help with this.
You noted earlier, the char device is really only needed if we want to
be able have multiple names for the same device, only exposed in
userspace.
If all we want to do is change the namespace for devices the kernel
uses, from "ethN" to something else, we can do that with a single
simple rename. And biosdevname has several --policy=[] options to
provide that.
--policy=smbios_names => "Embedded NIC 1", "PCI2"
--policy=kernelnames => "eth0" (kind of pointless, but included for completeness)
--policy=all_ethN => "eth0..ethN" in ascending slot order, embedded
before slots, within a single slot in PCI
breadth-first order, and thereafter in MAC
address order if really needed.
--policy=all_names => "eth_s0_0" for the first embedded NIC in PCI
breadth-first order, "eth_s1_1" for the
second NIC port in PCI slot 1, again in
breadth-first order.
--policy=embedded_ethN_slots_names a combo of the above, but making
the embeddeds still retain the "eth0" format
and the slots get "eth_s1_1" format.
We could add a dozen more. all_ethN, and to a lesser extent,
embedded_ethN, are bad choices if biosdevname is invoked by udev on
every run (e.g. not using persistent rules), because when it's run,
userspace doesn't know if there are more drivers to be loaded yet, and
so biosdevname can't know if there are more NICs to
include in the enumeration, to get the naming right. (yet another
example of enumeration != naming).
Now, for --policy=smbios_names, we get lucky in that the string length
returned from SMBIOS is 14 characters, it fits in IFNAMSZ. We may not
always get so lucky, SMBIOS strings are arbitrary lengths. This works
somewhat better as a symlink source, as that can be longer than
IFNAMSZ long.
--policy=all_names is pretty good. It fits, it lines up to a fairly
obvious hardware mapping. It breaks any code that assumes a regular
expression eth[[:digit:]]+ for the name.
By having a single name in the kernel for a particular device, it
forces a sysadmin to choose one naming policy. We can't have multiple
names for the same device (like we do for disks). And conceptually,
I'd like to be able to have a physical-based naming scheme (all_names)
for use at installtime and mechanical configuration, and a
logical-based naming scheme for firewall rules and other policy-based
configuration. I can't do that with a single name.
I can't please everyone. I can't keep the kernel's eth* namespace
intact, as it is meaningless and non-deterministic. I can switch
names to another namespace, at the risk of breaking all the
applications that have bad assumptions. And I can't have multiple
names for the same device. But if I have multiple names for the same
device, then I can keep the eth* namespace intact (meaningless as it
is), and provide more meaningful names that work too.
I'm not hung up on the char device. If I could have multiple names
for the same device, done entirely inside the kernel, I'd go for that
too. That suggestion has met similar resistance. Or any other
mechanism, I'm open to also. But _not_ solving it is no longer an
option for me and my customers.
--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
From: Dan Williams <hidden> Date: 2009-10-13 18:18:08
On Mon, 2009-10-12 at 14:41 -0500, Karl O. Pinc wrote:
On 10/12/2009 02:09:00 PM, Greg KH wrote:
quoted
"LOM"?
"LAN On Motherboard" of all things.
(I had to look this
one up. The expansion better suited
to today's economy is "Low On Manna".)
Or the previous usage from Sun, Apple, and others: "Lights Out
Management". Not sure why they needed to clash with a name already used
in server-space, but perhaps I'm just out-of-date and there's a fancier
name for LOM these days, and LOM got repurposed.
Dan
From: Ben Hutchings <hidden> Date: 2009-10-13 18:56:09
On Tue, 2009-10-13 at 11:17 -0700, Dan Williams wrote:
On Mon, 2009-10-12 at 14:41 -0500, Karl O. Pinc wrote:
quoted
On 10/12/2009 02:09:00 PM, Greg KH wrote:
quoted
"LOM"?
"LAN On Motherboard" of all things.
(I had to look this
one up. The expansion better suited
to today's economy is "Low On Manna".)
Or the previous usage from Sun, Apple, and others: "Lights Out
Management". Not sure why they needed to clash with a name already used
in server-space, but perhaps I'm just out-of-date and there's a fancier
name for LOM these days, and LOM got repurposed.
It's widely used with both meanings - what's more, LOM is an expected
feature of LOMs. :-)
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.