lee <[email protected]> wrote: > > So the names will not change when rebooting and are to be expected to > possibly change at any time.
/at any time/when you open the computer and mess around with the hardware/ Your whining in many postings becomes meanwhile unbearable. Just face the facts: Unless somebody comes up with an ingenious new idea there are essentially only 3 possibilities: 1. One gives names in order of detection. 2. One binds the name to the card. 3. One binds the name to general attributes (e.g. card type, slot type, ...) 4. One binds the name to the slot. No matter what is chosen, all has big disadvantages: For 1: The name will reproducible survive a booting _only_ if (a) There is no other card (b) There is no other driver which can act as a card (e.g. IP over firewire) There are many changes in hard- or software which can cause this to happen (booting from a rescue CD which has all drivers enabled; desktop user trying a new kernel; a user in a PC pool plugging in an USB stick with extra functionality; ...) My opinion: This is the most unreliable of all solutions and has much potential of making a distant machine inaccessible or to confuse unexperienced users. As far as I understand, one of the main reasons why udev was written was to avoid these problems. For 2: It survives rebooting, but it requires manual interaction (and more important: knowing and thinking about it) if e.g. the network card breaks and gets exchanged. This was implemented in previous versions of udev as default, but the implementation was buggy in a way which could not be fixed easily because of races. (It could have been fixed by using another namespace than eth*) My opinion: Many people have complained about this solution either, because of the above mentioned problem. Moreover, the above problem even happens if there is only one card. It is a pity that udev has removed this possibility completely and not left it (the variant without the bug) as an option which is simple to achieve. For 3: It has the same problems as 1, though they can be mitigated, since e.g. USB ports or certain known-to-cause-problems drivers can be treated separately. My opinion: This is what I use on my machines; however, using it as a default does not make sense, since it requires pre-knowledge on how the machine is meant to be used and which hardware is intended to be used. However, it would be nice, if udev would make it easy to use such rules (e.g. to have a numbering of all PCI cards in a certain namespace [e.g. eth_pci*] in the order of their detection); the problem is that this is not easy to implement without any race (which was the implementation problem of 2). For 4: This is the "new" (meanwhile many years old) possiblity of udev and has been chosen as the default when it was introduced. It survives booting and even an exchange of a network card and does not have the problems of 1 and 3, but it changes when you move the card to a different slot, and the rules are complicated if you do not know the hardware very well. My opinion: Only 2 and 4 reliably survive a boot on _any_ hardware without previous manual configuration. Since 4 is less likely to cause problems for hardware exchange than 2, this is a sane default. I would recommend everybody to change to 3 if he can, but for a generic rescue system or a yet unconfigured system 4 is the correct choice.
