On Sat, 2009-10-10 at 14:06 -0700, Greg KH wrote: > On Sat, Oct 10, 2009 at 11:32:19AM -0700, Stephen Hemminger wrote: > > > > BTW, for our distro, we are looking into device renaming based on PCI slot > > because that is what router OS's do. Customers expect if they replace the card > > in slot 0, it will come back with the same name. This is not what server > > customers expect. > > If your bios exposes the PCI slots to userspace (through the proper ACPI > namespace), doing this type of naming should be trivial with some simple > udev rules, no additional kernel infrastructure is needed. By and large, the people that care most about persistent network device names based on *location in the machine* are server users. This allows hotswap of cards or single-image-multiple-machine without needing configuration changes, which is nice. Those users can reasonably be expected to choose hardware whose BIOS supports the ACPI tables that (mostly) guarantee to provide actual, stable names for their hardware. If there's even a 10% chance that on consumer-level systems the names won't be stable on a given boot (and I can't see how, without BIOS support, we can guarantee 100% stability) then it's a worthless guarantee. If the BIOS support exists, it is trivial to use udev to create the correct naming mechanism for your machine, either using MAC address or BIOS-provided slot naming. No kernel patch is required. If the BIOS support does not exist, you are not guaranteed a stable naming mechanism except by MAC address, because the BIOS may randomly change enumeration based on the time of day, or it may not. A 90 or 95% stability guarantee is not a guarantee at all. Third, USB enumeration will always be unstable. Thus we have an unsolvable discrepancy in behavior between PCI and USB. Is this correct? Dan -- 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
