On Sun, Aug 30, 2020 at 12:43:51AM +0200, Pavel Machek wrote:

Hi!

quoted

quoted

quoted

And no, I don't want phydev name there.

Ummm. Can we get little more explanation on that? I fear that LED
device renaming will be tricky and phydev would work around that
nicely.

Hi Pavel

The phydev name is not particularly nice:

!mdio-mux!mdio@1!switch@0!mdio:00
!mdio-mux!mdio@1!switch@0!mdio:01
!mdio-mux!mdio@1!switch@0!mdio:02
!mdio-mux!mdio@2!switch@0!mdio:00
!mdio-mux!mdio@2!switch@0!mdio:01
!mdio-mux!mdio@2!switch@0!mdio:02
!mdio-mux!mdio@4!switch@0!mdio:00
!mdio-mux!mdio@4!switch@0!mdio:01
!mdio-mux!mdio@4!switch@0!mdio:02
400d0000.ethernet-1:00
400d0000.ethernet-1:01
fixed-0:00

Not nice, I see. In particular, it contains ":"... which would be a
problem.

quoted

The interface name are:

1: lo:
2: eth0:
3: eth1:
4: lan0@eth1:
5: lan1@eth1:
6: lan2@eth1:
7: lan3@eth1:
8: lan4@eth1:
9: lan5@eth1:
10: lan6@eth1:
11: lan7@eth1:
12: lan8@eth1:
13: optical3@eth1:
14: optical4@eth1:

OTOH... renaming LEDs when interface is renamed... sounds like a
disaster, too.

I don't think it is. The stack has all the needed support. There is a
notification before the rename, and another notification after the
rename. Things like bonding, combing two interfaces into one and load
balancing, etc. hook these notifiers. There is plenty of examples to
follow. What i don't know about is the lifetime of files under
/sys/class/led, does the destroying of an LED block while one of the
files is open?.

quoted

You could make a good guess at matching to two together, but it is
error prone. Phys are low level things which the user is not really
involved in. They interact with interface names. ethtool, ip, etc, all
use interface names. In fact, i don't know of any tool which uses
phydev names.

So... proposal:

Users should not be dealing with sysfs interface directly, anyway. We
should have a tool for that. It can live in kernel/tools somewhere, I
guess.

We already have one, ethtool(1). 

Would we name leds phy0:... (with simple incrementing number), and
expose either interface name or phydev name as a attribute?

So user could do

cat /sys/class/leds/phy14:green:foobar/netdev
lan5@eth1:

Which is the wrong way around. ethtool will be passed the interface
name and an PHY descriptor of some sort, and it has to go search
through all the LEDs to find the one with this attribute. I would be
much more likely to add a sysfs link from
/sys/class/net/lan5/phy:left:green to
/sys/class/leds/phy14:left:green.

	Andrew