quoted

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

quoted

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:

I forgot about network name spaces. There can be multiple interfaces
with the name eth0, each in its own network namespace. For your
proposal to work, /sys/class/leds/phy14:green:foobar needs to be in
the network namespace, so it is only visible to other processes in the
same name space, and lan5@eth1 is then unique to that namespace.

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.

I need to test a bit, but i think this works. Everything under
/sys/class/net is network namespace aware. You only see
/sys/class/net/lan5 if there is a lan5 is in the current name space,
and you see the current namespaces version of lan5.. A sysfs symlink
out of namespace to /sys/class/led should work, assuming
/sys/class/led is namespace unaware, and phy14 is unique across all
network name spaces. But you cannot have a link in the opposite
direction from /sys/class/led/phy14 to /sys/class/net/lan5, since it
has no idea which lan5 to symlink to.

    Andrew