Le 26/08/2017 à 19:02, Alessandro Selli a écrit :
On Sat, 26 Aug 2017 at 17:19:48 +0200
Didier Kryn <k...@in2p3.fr> wrote:
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.
This is not a good solution when you want networking to work just the same
even when you replace or shuffle your networking hardware around, expecially
with USB devices.
Please could you explain why with more details?
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.
This is easily done on filesystems, because you can assign arbitrary UUIDs
and LABELs on a filesystem at mkfs time or later with tune2fs and other tools.
But you cannot as easily change MAC address on an ethernet or WiFi device,
sometimes you cannot do it at all (AFAIK in some cases you should reflash an
internal flash memory).
You assign UUIDs because partitions dont come with hardwired UUIDs,
obviously. The usefull property of UUIDs is in their name ("unique"),
not at all the fact that you (randomly) assign them. The same applies to
MAC addresses, they are (quasi) unique.
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.
Because in most cases networking on eth0 must work no matter what it's MAC
address is today/was yesterday.
The problem is how to configure eth0. If you have only one nic,
then it's clear; otherwise you don't want to mess.
With my proposed solution, the admin has the choice to refer to
nics by their interface name, as given by the kernel, which is fine when
there is only one, or by their MAC address, if there are several. If you
use MAC you get the same result as with current Devuan's udev renaming
scheme -without the race - and if you use eth0 then you get the same
result as if you disabled renaming. And you can mix things if you like
in /etc/interfaces, eg use wlan0 for wifi and MAC for the Ethernets; it
isn't a decisipon of the distro; it is up to the admin. Just like for
partitions. Simplicity and choice, that's Unix, isn't it :-)
And why are the potterguys now promoting their
complicated name space, if not to make the system always more complicated
I do agree their solution is far from elegant.
to solve a problem they have invented themselves?
I do not agree: in many cases when a machine has several NICs there are
real issues with the kernel's naming scheme.
Seems (to me) you didn't get my point. Sorry I failed to explain or
I failed to understand your objections :-)
Didier
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
