On Thu, Jan 24, 2013 at 1:07 AM, John Reiser <jrei...@bitwagon.com> wrote: > On 01/23/2013 02:49 PM, Kay Sievers wrote: > >> Just looking at 'lspci' will in most >> cases tell you what the name of the network interface will be. > > This is not true for my machines, which I built using main boards > from ASUS, MSI, etc.
It certainly is true for every PCI based machine. The default names are strictly what you see in lspci. It's decimal instead of hex, maybe that's what you missed? > The port numbers listed by 'lspci' (thus part of > the default udev name) do NOT correspond to slot numbers in any simple way. They do, just that they are the PCI geography, not the slot number in the sense of the physical slot number you see printed on your board. 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. > Therefore the udev name requires translation in order to find > the right cable. This is not good. If your firmware supports on-board interfaces, or you use properly firmware-supported PCI hotplug slots, udev names will use exactly these "pretty" numbers, not the "ugly" geographical ones. You can even recognize these firmware supported numbers in the udev names, because they use a different prefix. > biosdevname has the advantage that I can determine the mapping > between cable and interface name by looking at the back of the > machine (where the cables plug in) Udev provides exactly the same without the "guessing" part. If the firmware does not provide authoritative information, udev always uses the geography, which is the safest (granted not the prettiest) thing to do. > and counting slots first, then jacks per slot. Anything that *counts* on its own, ever, is doomed to fail in the context of stable name creation. It is in the end not much better than the kernel that just *counted* ethX upwards. The very idea of counting here is the main flaw that lead to the decision that we cannot use the biosdevname scheme in udev. It just cannot work, because you introduce inter-device dependencies, which are not predictable regarding re-configuration. Udev strictly only uses information of the one and single device it handles, never of any of its siblings, because that is where the problem starts, and which cannot be solved in the end. > biosdevname has handled the mapping between > physical slot and logical PCI port. Sure, and udev does the same, if the firmware supports it. But biosdevname went too far if the firmware lacked the information, and it "invented" new numbers, based on fragile heuristics and internal counters -- things which we should strictly avoid. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
