>
david@lang.hm wrote:
>> On Thu, 2 Aug 2007, Ondrej Zajicek wrote:
>>> On Thu, Aug 02, 2007 at 01:47:23PM +0200, Jan Engelhardt wrote:
>>>> It does not rename ethX to the "next free" one, but to a _persistent_ one.
>>>> If it were a "next free" thing, then removing a card would shuffle all
>>>> your eth around again (and invalidate your iptables rules at the same
>>>> time, to note).
>>>
>>> It is questionable what is _persistent_ . MAC-based names are persistent
>>> with regard to adding and removing of other cards, 'Plain' names are persistent
>>> with regard to replacing that card with different item (of a same kind).
>>>
>>> I am very happy that (using 'plain' names) i can send technician to
>>> replace broken NIC in our routers without need for configuration
>>> change.
>>
>> this is a very important point, and with the distros (and many kernel
>> people) treating udev as a requirement this is going to bite a lot of
>> people.
>
> Two notes:
>
> 1. Udev doesn't restrict you to any one naming scheme. If you want
> something else than a MAC based scheme, e.g. a PCI topology based
> scheme, udev most certainly can do that for you. But the kernel can't.
>
> 2. Consider udev a kernel extension in userspace, with the benefit of
> configurability and scriptability, features that kernel extensions in
> kernelspace can't offer. Of course this gain of features doesn't come
> at zero cost: You need a minimal userspace environment at boot time.
>
> Quoting myself from
http://marc.info/?l=linux-scsi&m=118613786003162:
>
> 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) 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.
>
> There is only the most primitive naming scheme implemented in the kernel
> because naming policy, like most other kinds of policy, is better left
> to userland. The kernel is a too restricted framework to implement such
> things. The kernel lacks runtime-configuration files, scripting
> interfaces, et cetera.
