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

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?

Marek

Powered by blists - more mailing lists