On Sun, 27 Sep 2020 02:29:35 +0200
Andrew Lunn <andrew@xxxxxxx> wrote:
> On Sun, Sep 27, 2020 at 12:40:25AM +0200, Marek Behun wrote:
> > Hi,
> >
> > linux-leds is trying to create a consistent naming mechanism for LEDs
> > The schema is:
> > device:color:function
> > for example
> > system:green:power
> > keyboard0:green:capslock
> >
> > But we are not there yet.
> >
> > LEDs are often dedicated to specific function by manufacturers, for
> > example there can be an icon or a text next to the LED on the case of a
> > router, indicating that the LED should blink on activity on a specific
> > ethernet port.
> >
> > This can be specified in device tree via the trigger-sources property.
> >
> > We therefore want to select the device part of the LED name to
> > correspond to the device it should trigger to according to the
> > manufacturer.
> >
> > What I am wondering is how should we select a name for the device part
> > of the LED for network devices, when network namespaces are enabled.
> >
> > a) We could just use the interface name (eth0:yellow:activity). The
> > problem is what should happen when the interface is renamed, or
> > moved to another network namespace.
> > Pavel doesn't want to complicate the LED subsystem with LED device
> > renaming, nor, I think, with namespace mechanism. I, for my part, am
> > not opposed to LED renaming, but do not know what should happen when
> > the interface is moved to another namespace.
> >
> > b) We could use the device name, as in struct device *. But these names
> > are often too long and may contain characters that we do not want in
> > LED name (':', or '/', for example).
> >
> > c) We could create a new naming mechanism, something like
> > device_pretty_name(dev), which some classes may implement somehow.
> >
> > What are your ideas about this problem?
>
> I lost track of where these file will appear. I was surprised with the
> location in the first proposal
>
> Looking at one of my systems we have:
>
> ls -l /sys/class/net/eth0/
> total 0
> -r--r--r-- 1 root root 4096 Sep 26 14:34 addr_assign_type
> -r--r--r-- 1 root root 4096 Sep 26 14:34 address
> -r--r--r-- 1 root root 4096 Sep 26 19:06 addr_len
> -r--r--r-- 1 root root 4096 Sep 26 19:06 broadcast
> ...
> phydev -> ../../mdio_bus/400d0000.ethernet-1/400d0000.ethernet-1:00
> ...
>
> Will the LED class directory appear as a subdirectory of
> /sys/class/net/eth0/, or a subdirectory of
> ../../mdio_bus/400d0000.ethernet-1/400d0000.ethernet-1:00 or in
> /sys/class/leds?
>
> If they are in /sys/class/led, the name needs to be globally
> unique. That rules out using the interface name, which is not globally
> unique, it is only netns unique.
>
> If they are inside /sys/class/net/eth0, we don't need to worry about
> the name, we know which interface they belong to simply from the
> parent directory. We can then use "phy:yellow:activity".
>
> The same applies for
> "../../mdio_bus/400d0000.ethernet-1/400d0000.ethernet-1:00". The user
> can follow the symlink from /sys/class/net/eth0 to the phy directory
> to find the LEDs for a PHY.
>
> Andrew
Andrew,
the directory is always, for every device in kernel, in /sys/devices
somewhere, in hierarchy corresponding to dev->parent pointers.
Everything else is via symlink.
/sys/class/net/eth0 is a symlink to something in /sys/devices somewhere.
/sys/class/net/eth0/phydev is a symlink to phydev in /sys/devices
somewhere.
If the phydev has children devices of class "leds", then its directory
will contian "leds" subdirectory, and this "leds" subdirectory will
contain subdirectories corresponding to each LED registered under the
phydev.
So I will have
/sys/class/net/eth0/phydev/leds/eth0:green:activity
| |
symlink |
|
symlink
and I will also have
/sys/class/leds/eth0:green:activity
|
symlink
For every X in /sys/class/*/X, X is symlink to something in
/sys/devices.
Even bridge devices are symlinks:
kabel@thinkpad ~ $ ls -l /sys/class/net/br0
lrwxrwxrwx 1 root root 0 Sep 20 14:41 /sys/class/net/br0 -> ../../devices/virtual/net/br0
Marek
