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]

Message-ID: <20200927025258.38585d5e@nic.cz>
Date:   Sun, 27 Sep 2020 02:52:58 +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: Re: Request for Comment: LED device naming for netdev LEDs

On Sun, 27 Sep 2020 00:40:25 +0200
Marek Behun <marek.behun@....cz> wrote:

> 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

BTW option b) and c) can be usable if we create a new utility, ledtool,
to report infromation about LEDs and configure LEDs.

In that case it does not matter if the LED is named
  ethernet-adapter0:red:activity
or
  ethernet-phy0:red:activity
because this new ledtool utility could just look deeper into sysfs to
find out that the LED corresponds to eth0, whatever it name is.

Still does not solve namespaces, though, because ethernet PHY devices
(struct phy_device) do not currently support network namespaces.

Marek