:: Re: [DNG] What does Linus do?
Página Principal
Delete this message
Reply to this message
Autor: Alessandro Selli
Data:  
Para: dng
Assunto: Re: [DNG] What does Linus do?
On Sat, 26 Aug 2017 at 15:04:51 +0200
Didier Kryn <kryn@???> wrote:

> Le 26/08/2017 à 14:14, Alessandro Selli a écrit :
>>>       My main subject was questionning the necessity of renaming network
>>> interfaces (with my answer to the question). Since nobody argumented
>>> that renaming was necessary, it is clear for me that renaming is a
>>> feature invented to give more importance to Udev and isn't necessary at
>>> all.  
>>    Actually Adam Borowski did.  Did you miss this message of his posted on
>> the 20th?
>> https://lists.dyne.org/lurker/message/20170820.142726.04720725.en.html  

>
>      Adam proposed that the renaming happens in a different namespace so 
> as to not clash with kernel naming new interfaces asynchronously. At 
> this stage of the thread, the necessity of interface renaming was not 
> yet questioned; at least this mail of Adam was not an opinion on wether 
> renaming was necessary/useful or not.


Yes, this necessity was argued in the linked email. I quote:

    * interface names changing randomly at boot are nasty for machines
      with multiple non-bonded interfaces. As drivers are loaded by the
      kernel in parallel, they're inherently racey, thus kernel ordering
      may change.


That is, Adam acknowledges there exists an issue with the kernel's
assignment of ethernet device names on "machines with multiple non-bonded
interfaces." And he did not argue against the necessity of interface
renaming in userland, in fact he proposed his own naming scheme:

    Thus, I think the best long-term solution would be writing a
    generation, using either *udev or ifupdown, that learns new
    interfaces as they come, and names them using a single namespace
    that's not "eth0"/"wlan0". In particular, a machine with only a
    single interface (ie, 99% of them) would predictably have en0 and
    possibly wl0.


    But sticking with just kernel names would still be much better than
    the enp0s3 idea. It'd be _predictable_ in that 99% case; machines
    with multiple interfaces tend to be either routers (which come
    preconfigured) or servers (which have an admin who's supposed to have
    a clue).



Alessandro