Didier Kryn <kryn@???> writes:
> Le 22/06/2016 09:08, Simon Hobson a écrit :
>> If you just use the default kernel naming scheme then you open
>> yourself to the problem that udev was designed to solve - that of
>> random device names. I do have personal experience of that - boot
>> with a different disk (for maintenance) and eth0 & eth1 swap places
>> (can't remember if it was "stable" when using just the main OS). And
>> I've first hand experience of the "two disk controllers" problem
>> where it really was random which disk was sda and which was sdb. But
>> once you go down the route of udev (or equivalent, eg vdev) and
>> persistent rules, then "eth0" is just a subset of "admin set
>> interface name".
>

>     Udev solved the problem of the stability of device names: once one
> interface has been named eth0, the same interface will remain eth0 - 
> without interference from the admin.

Unless the admin transfers the installation to another system. Assuming
that everything used to work fine with eth0 - eth3, all hell will
break lose because the sole four interfaces are now called eth4 - eth7.

The idea is already conceptually rotten as MAC addresses are usually
programmable and may even be randomly generated.

> But it does not solve the problem which Rainer adresses: to match the
> device name with the visual labelling, ie the need for a predictable
> matching between interface name and what is written on the box, so
> that instructions to the user make sense.

That's something I specifically don't care about. Any mapping is good
provided it's possible to write software such that it doesn't have to
care about the hardware it's going to run on and that it's stable.

There's no way to predict external wiring from the bus geometry, only
the hardware manufacturer knows about that.