On Sat, 26 Aug 2017 at 13:11:36 -0400 Hendrik Boom <hend...@topoi.pooq.com> wrote:
> On Sat, Aug 26, 2017 at 07:02:41PM +0200, Alessandro Selli wrote: >> 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. > > It seems we are approaching the paradox of the well-darned sock. > At what point are we to consider an interface to have changed? Right, both the admin and the system will easily agree on the fact that an interface is new. But what about it's name to be assigned? Is it new because it's replacing a previouly used interface, or is it new because it's going to be used for something unrelated to the other interfaces that the system has seen before? how is the OS supposed to know? It cannot, so any NIC renaming gimmick will have to provide for a way the sysadmin to impose their own naming scheme. My vote will go to the system that: 1) uses the shortest and easiest to identify and remember names (en0 and wf1 are good choises, enp0s23 so so, etf45a09dc634 is awful) 2) is as easy as apple pie to reconfigure to fit any specific environment (which is a thing udev got wrong). Alessandro _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng