Gentoo Archives: gentoo-user

From: Rich Freeman <rich0@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: eno1 became back eth0
Date: Thu, 14 Nov 2019 16:44:28
Message-Id: CAGfcS_kdy5F=tJEPEW_P=eYms00Ss-d5aoZxxUOb4sVwUEG5GA@mail.gmail.com
In Reply to: [gentoo-user] Re: eno1 became back eth0 by Grant Edwards
1 On Thu, Nov 14, 2019 at 11:21 AM Grant Edwards
2 <grant.b.edwards@×××××.com> wrote:
3 >
4 > The way it was explained to me was that the old way fell down in some
5 > situations with multiple interfaces. Interfaces were named in the
6 > order they were disovered by the kernel during startup. For some
7 > sorts of NICs (e.g. PCI) the discovery order is repeatible, so no
8 > problems.
9 >
10 > However, for some sorts of interfaces (e.g. USB attached devices), the
11 > discovery order isn't always repeatable. The new scheme was
12 > implemented to make sure than every time you reboot you get interface
13 > names that corresponded to the same physical RJ45 jacks they did the
14 > last time.
15
16 Another issue is that network interfaces wasn't something really
17 accommodated in the original unix design, which is why they don't show
18 up in /dev. I think on plan9 this was remedied, but of course nobody
19 uses that.
20
21 If they did show up as devices then we could use symlinks such as with
22 /dev/disk/by-id and so on to provide more flexible solutions. I don't
23 think it is possible to have the same physical interface have multiple
24 names in the kernel so that you can have both eth0 and the new scheme
25 side-by-side.
26
27 I'd suggest that they should be named by MAC but of course even this
28 is malleable in some situations, and there is promiscuous mode as
29 well.
30
31 Persistent device names are tricky in a lot of situations, really.
32 Back when I was running mythtv I had multiple pl2303 devices and
33 keeping those straight required writing udev rules that created
34 symlinks based on the physical host port they were plugged into, which
35 is of course non-ideal in USB land. It is less of an issue for
36 hardware that is sophisticated enough to present its own UUID.
37
38 --
39 Rich