On Thu, Oct 07, 2010 at 08:11:34AM -0700, Greg KH wrote: > On Thu, Oct 07, 2010 at 07:23:35AM -0700, Narendra_K@xxxxxxxx wrote: > > Hello, > > > > V1 -> V2: > > > > This patch addresses the scenario of buggy firmware/BIOS tables. The > > patch introduces a command line parameter 'no_netfwindex', passing which > > firmware provided index will not be used to derive 'eth' names. By > > default, firmware index will be used and the parameter can be used to > > work around buggy firmware/BIOS tables. > > > > Please find the patch below. > > > > From: Narendra K <narendra_k@xxxxxxxx> > > Subject: [PATCH] Use firmware provided index to register a network device > > > > This patch uses the firmware provided index to derive the ethN name. > > If the firmware provides an index for the corresponding pdev, the N > > is derived from the index. > > No, this has the very big chance to reorder existing network names and > should all be done in userspace with the firmware information exported > in sysfs, if the user so desires. Existing names that use 70-persistent-net.rules won't change. They were non-deterministically assigned and recorded in that file, so they'll persist. At most, they'll have to deal with the same "eth0_rename" garbage that anyone wanting to get a consistent name from other than MAC address would get. The only reason the auto-created 70-persistent-net.rules works is that most people don't change their NIC configuration after install, so it has no renaming to do. The kernel patch has the advantage of not requiring users to change their scripts, by reserving the first N values for onboard devices as BIOS describes them. Userspace udev rules require us to change user behavior, and likely their scripts, to use a new namespace such as ethlom1, in order to get deterministic naming. > > It took some time to find out the details asked above. Right, > > windows does not use SMBIOS type 41 record to derive names. But as > > a datapoint, windows also has the same problem. > If windows does not use this field, then you can guarantee it will > show up incorrectly in BIOSes and never be tested by manufacturers > before they ship their machines. There are 2 methods of exporting the information that have gotten confusing here. 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. 2) soon-to-be-released PCIe Firmware Spec, exporting label and index as an ACPI _DSM(). It is anticipated that Windows will use this information in some fashion at some point, per our conversations with Microsoft as part of the PCI SIG proposal process. We've held off submitting a kernel patch until the spec is public. Cases: 1) BIOS doesn't provide this information (the common case today for all but Dell 10G and newer servers), nothing is reserved, and therefore the existing 70-persistent-net.rules take effect to name devices. No change in behavior for existing systems. New installs will have NICs named non-deterministically, and recorded in 70-persistent-net.rules. Users desiring consistent naming must adjust 70-persistent-net.rules after install, and to avoid eth0_rename collisions, must rename into another namespace. 2) BIOS provides this information correctly (Dell 10G and newer servers, or anyone else implementing the spec). The first N values for onboard devices are reserved and assigned by the kernel to onboard devices. 70-persistent-net.rules may still try to rename the ports, and may fail with eth0_rename collisions. Users would have to adjust 70-persistent-net.rules to accommodate, but they do not have to change the namespace from ethX to something else. New installs will have onboard NICs named deterministically, and recorded in 70-persistent-net.rules. 3) BIOS provides this information incorrectly (none known today). Some number of N values may be reserved, more or fewer than actually present. In either case, it's possible that 70-persistent-net.rules would have to be adjusted to accommodate, but they do not have to change the namespace from ethX to something else. New installs will have onboard NICs named deterministically, if not ideally due to buggy BIOS, and recorded in 70-persistent-net.rules. What I can't find here is a solution where the user gets determistic naming, without being forced to change the namespace and adjust their scripts. Can anyone? I'm not opposed to "do it all in userspace" - really, I'm not. But the 'where' is only part of the problem. No userspace solution has yet been proposed that doesn't require a namespace change, and I'm still hoping to avoid that. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
