On Mon, Oct 12, 2009 at 01:47:12PM -0500, Narendra K wrote: > > On Mon, Oct 12, 2009 at 01:45:28PM -0400, Bill Nottingham wrote: > > > Greg KH (greg@xxxxxxxxx) said: > > > > > 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). > > > > > 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, > > > > > > 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? > > > 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 :) > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
