:: Re: [DNG] What does Linus do?
Página Principal
Delete this message
Reply to this message
Autor: Didier Kryn
Data:  
Para: dng
Assunto: Re: [DNG] What does Linus do?
Le 26/08/2017 à 16:35, Alessandro Selli a écrit :
> 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).

>

     AFAIR I fully agreed on that and then it jumped into my face that 
the renaming wasn't necessary at all, because it is sufficient to know 
the MAC address and ignore completely the interface name. It is just 
enough for this to work that the tools manipulating the network 
interfaces can be given the MAC address instead of the interface name. 
This opens an alternative to renaming: guaranteed stable interface 
reference, no race condition and no need for a new name space.


     Since this last method is exactly what is done to refer to disk 
partitions in both the mount utility and the fstab, the same could be 
done with the MAC address of the network interfaces. Which raises 
another question: why are we using the hotplugger to mess with interface 
names instead of implementing the MAC handle in the ip utility and the 
interfaces file. And why are the potterguys now promoting their 
complicated name space, if not to make the system always more 
complicated to solve a problem they have invented themselves?


     Didier