[gentoo-user] Re: from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Martin Vaeth <martin@mvath.de>]

lee <lee@yagibdah.de> 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.