netdev - Re: devicename part of LEDs under ethernet MAC / PHY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 1 Oct 2021 14:40:53 +0200
From:   Marek Behún <kabel@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Pavel Machek <pavel@....cz>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        netdev@...r.kernel.org,
        Jacek Anaszewski <jacek.anaszewski@...il.com>
Subject: Re: devicename part of LEDs under ethernet MAC / PHY

On Fri, 1 Oct 2021 14:29:17 +0200
Andrew Lunn <andrew@...n.ch> 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.

> > Note that this names are visible to userspace as symlinks
> > /sys/class/leds directory. If they are unstable, it is not that big an
> > issue, because mostly these LEDs should be accessed via
> > /sys/class/net/<interface>/device/leds for eth MAC LEDs and via
> > /sys/class/net/<interface>/phydev/leds for eth PHY LEDs.  
> 
> Yes, this also handles network name space nicely.
> 
> > If we wanted to make these names stable, we would need to do something
> > like
> >   ethphy-BUS-ID
> > for example
> >   ethphy-usb3,2
> >   ethmac-pci0,19,0
> >   ethphy-mdio0,1
> > or
> >   ethmac-DEVICE_PATH (with '/'s and ':'s replaced with ',' or something)
> > for example
> >   ethphy-platform,soc,soc,internal-regs,f10f0000.usb3,usb3,3-0,1:0  
> 
> I guess Systemd can be extended to do this, maybe, rename the LEDs
> when it renames the interface? This is not really a kernel problem.

Pavel is against LED classdev renaming.

Marek