netdev - Re: Request for Comment: LED device naming for netdev LEDs

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:   Sun, 27 Sep 2020 02:45:22 +0200
From:   Marek Behun <marek.behun@....cz>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev <netdev@...r.kernel.org>, linux-leds@...r.kernel.org,
        David Miller <davem@...emloft.net>,
        Russell King <linux@...linux.org.uk>
Subject: Re: Request for Comment: LED device naming for netdev LEDs

On Sun, 27 Sep 2020 02:29:35 +0200
Andrew Lunn <andrew@...n.ch> 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@...nkpad ~ $ ls -l /sys/class/net/br0
lrwxrwxrwx 1 root root 0 Sep 20 14:41 /sys/class/net/br0 -> ../../devices/virtual/net/br0

Marek