Hello Greg, could you give your opinion on this discussion? Are device names (as returned by dev_name() function) also part of sysfs ABI? Should these names be stable across reboots / kernel upgrades? Marek On Fri, 1 Oct 2021 14:40:53 +0200 Marek Behún <kabel@xxxxxxxxxx> wrote: > On Fri, 1 Oct 2021 14:29:17 +0200 > Andrew Lunn <andrew@xxxxxxx> wrote: > > > > - Andrew proposed that the numbering should start at non-zero number, > > > for example at 42, to prevent people from thinking that the numbers > > > are related to numbers in network interface names (ethN). > > > A system with interfaces > > > eth0 > > > eth1 > > > and LEDs > > > ethphy0:green:link > > > ethphy1:green:link > > > may make user think that the ethphy0 LED does correspond to eth0 > > > interface, which is not necessarily true. > > > Instead if LEDs are > > > ethphy42:green:link > > > ethphy43:green:link > > > the probability of confusing the user into relating them to network > > > interfaces by these numbers is lower. > > > > > > Anyway, the issue with these naming is that it is not stable. Upgrading > > > the kernel, enabling drivers and so on can change these names between > > > reboots. > > > > Sure, eth0 can become eth1, eth1 can become eth0. That is why we have > > udev rules, systemd interface names etc. Interface names have never > > been guaranteed to be stable. Also, you can have multiple interfaces > > named eth0, so long as they are in different network name spaces. > > > > > Also for LEDs on USB ethernet adapters, removing the USB and > > > plugging it again would change the name, although the device path does > > > not change if the adapter is re-plugged into the same port. > > > > > > To finally settle this then, I would like to ask your opinion on > > > whether this naming of LEDs should be stable. > > > > No. They should be unstable like everything else. > > LED classdev names are something different. > For etherent interfaces, the interface name is different from name of > the underlying struct device. But LED classdev names are also > corresponding struct device names, and thus part of sysfs ABI, which, > as far as I understand, should be stable.
