netdev - 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-next>] [day] [month] [year] [list]

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

Hello Pavel, Andrew,

previously we discussed devicename part of LEDs connected under
ethernet MACs and/or ethrenet PHYs.

I would like to finally settle this, but there is one more thing that
may be problematic.

To remind the current proposal, discussed in previous e-mails:

- for LEDs under an ethernet PHY, the devicename part of the LED should
  be "ethphyN", with N an auto-incrementing number for each struct
  phy_device
- for LEDs under an ethernet MAC, it should be similar: "ethmacN"

- the numbers in ethmac and ethphy are unrelated and cannot be related

- 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. 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.

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.

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

The first scheme is nicer but would need some additional code for each
bus.
The second scheme is simpler to implement, but the naming is hideous -
the whole point of devicename part of LEDs was (in my understanding) to
be a nice name, like "mmc0".

Marek