>
david@lang.hm wrote:
>> On Fri, 3 Aug 2007, Stefan Richter wrote:
>>> There is a variety of possible naming schemes:
>>>
>>> - Naming by order of discovery.
>>> - Naming by vendor/model name strings.
>>> - Naming by universally unique identifier.
>>> - Naming by topology.
>>> - ...
>>>
>>> Only the simplest of these schemes (naming by order of discovery)
>
> (which is in most cases also the scheme that's the least useful to
> admins and users)
>
>>> is hardwired into the kernel portion of the Linux OS. The other naming
>>> schemes are (or can be) implemented in the userland portion of the
>>> Linux OS.
> ...
>> I understand the flexibility that this provides, unfortunantly (IMHO)
>> default udev rules (or at least what many distros are shipping by
>> default) changes from this simple naming scheme in a way that hides the
>> fact from the user. This means that many users will not even realize the
>> change in policy until the hardware changes and things don't act the way
>> they were expected to. In my case it was removing 3 quad cards from a
>> machine and finding that there was no eth0 on the box, instead there was
>> a eth12, this is fairly benign. what would have caused me significant
>> problems would have been having a card fail in a production box, have it
>> replaced and then found that the interfaces were now eth4-eth22 instead
>> of eth0-eth18. having the interfaces named differently on different
>> boxes with identical hardware based on the history of what has been
>> plugged into the boxes in the past is not what sysadmins expect.
>
> Yes, these rules by far don't fit everyone's needs. People who often
> use hotpluggable NICs are probably served best by MAC address based
> naming. Boxes with field replacable but otherwise fixed NICs apparently
> rather need a naming scheme based on PCI/PCIe topology. (This requires
> that the topology is exposed to userspace in comparable manner across
> boots and across kernel version updates.)
