On Thu, Jan 24, 2013 at 3:46 AM, Orion Poplawski <orion@xxxxxxxxxxxxx> wrote: > On 01/23/2013 05:29 PM, Kay Sievers wrote: >> >> What udev does here is the only sensible thing to do, if there is no >> authoritative information from the firmware about that, we don't make >> assumptions, we use the reasonable stable PCI geography. Guessing >> around which might the "human" slot number should be avoided for many >> reasons. > > > FWIW - I did a BIOS upgrade and reconfig on one of our machines and the PCI > slot numbers as shown in lscpi changed for our SATA controllers. Caused a > bit of panic when we ended up pulling the wrong drive. Yeah, we see that from time to time, sometimes even just by re-configuring things, not only on firmware upgrades. > Perhaps the BIOS > assisted names would have been more stable in this case for the ethernet > names, I don't know. It should, yes. Firmware provided index/slot/interface numbers seem to work pretty well so far. > I'm not trying to disparage this work, it seems reasonable (although I've > been bitten by a lot of crappy software assuming network devices are named > eth#, but it's able to be turned off, so meh). Right, it's a pain. Some software likes the eth* names to find the MAC address to use that as a machine-id. But all that already happens with biosdevname, and the reported issues seems pretty rare these days. > Just passing along a data > point. YMMV and all that. Thank you. Kay -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
