Le 26/08/2017 à 19:02, Alessandro Selli a écrit :
> On Sat, 26 Aug 2017 at 17:19:48 +0200
> Didier Kryn <kryn@???> 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
::
Re: [DNG] What does Linus do?
