1 |
lee <lee@××××××××.de> wrote: |
2 |
> |
3 |
> So the names will not change when rebooting and are to be expected to |
4 |
> possibly change at any time. |
5 |
|
6 |
/at any time/when you open the computer and mess around with the hardware/ |
7 |
|
8 |
Your whining in many postings becomes meanwhile unbearable. |
9 |
Just face the facts: |
10 |
Unless somebody comes up with an ingenious new idea there are |
11 |
essentially only 3 possibilities: |
12 |
|
13 |
1. One gives names in order of detection. |
14 |
|
15 |
2. One binds the name to the card. |
16 |
|
17 |
3. One binds the name to general attributes |
18 |
(e.g. card type, slot type, ...) |
19 |
|
20 |
4. One binds the name to the slot. |
21 |
|
22 |
No matter what is chosen, all has big disadvantages: |
23 |
|
24 |
For 1: The name will reproducible survive a booting _only_ if |
25 |
(a) There is no other card |
26 |
(b) There is no other driver which can act as a card |
27 |
(e.g. IP over firewire) |
28 |
There are many changes in hard- or software which can cause this |
29 |
to happen (booting from a rescue CD which has all drivers enabled; |
30 |
desktop user trying a new kernel; a user in a PC pool plugging |
31 |
in an USB stick with extra functionality; ...) |
32 |
|
33 |
My opinion: This is the most unreliable of all solutions and |
34 |
has much potential of making a distant machine inaccessible |
35 |
or to confuse unexperienced users. |
36 |
As far as I understand, one of the main reasons why udev was |
37 |
written was to avoid these problems. |
38 |
|
39 |
For 2: It survives rebooting, but it requires manual interaction |
40 |
(and more important: knowing and thinking about it) |
41 |
if e.g. the network card breaks and gets exchanged. |
42 |
This was implemented in previous versions of udev as default, |
43 |
but the implementation was buggy in a way which could not be |
44 |
fixed easily because of races. (It could have been fixed by using |
45 |
another namespace than eth*) |
46 |
|
47 |
My opinion: Many people have complained about this solution either, |
48 |
because of the above mentioned problem. Moreover, the above |
49 |
problem even happens if there is only one card. |
50 |
It is a pity that udev has removed this possibility completely and |
51 |
not left it (the variant without the bug) as an option which is |
52 |
simple to achieve. |
53 |
|
54 |
For 3: It has the same problems as 1, though they can be mitigated, |
55 |
since e.g. USB ports or certain known-to-cause-problems drivers can |
56 |
be treated separately. |
57 |
|
58 |
My opinion: This is what I use on my machines; however, using it as |
59 |
a default does not make sense, since it requires pre-knowledge on how |
60 |
the machine is meant to be used and which hardware is intended to |
61 |
be used. However, it would be nice, if udev would make it easy to |
62 |
use such rules (e.g. to have a numbering of all PCI cards in a |
63 |
certain namespace [e.g. eth_pci*] in the order of their detection); |
64 |
the problem is that this is not easy to implement without any race |
65 |
(which was the implementation problem of 2). |
66 |
|
67 |
For 4: This is the "new" (meanwhile many years old) possiblity of udev |
68 |
and has been chosen as the default when it was introduced. |
69 |
It survives booting and even an exchange of a network card and does not |
70 |
have the problems of 1 and 3, but it changes when you move the card |
71 |
to a different slot, and the rules are complicated if you do not |
72 |
know the hardware very well. |
73 |
|
74 |
My opinion: Only 2 and 4 reliably survive a boot on _any_ hardware |
75 |
without previous manual configuration. Since 4 is less likely to |
76 |
cause problems for hardware exchange than 2, this is a sane default. |
77 |
I would recommend everybody to change to 3 if he can, but for a |
78 |
generic rescue system or a yet unconfigured system 4 is the correct |
79 |
choice. |