Le 26/08/2017 à 16:35, Alessandro Selli a écrit :
On Sat, 26 Aug 2017 at 15:04:51 +0200
Didier Kryn <k...@in2p3.fr> 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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
