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.

>      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).

> 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.

> 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.


Alessandro