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
::
Re: [DNG] What does Linus do?
