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-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 27 Sep 2020 02:52:58 +0200
From:   Marek Behun <>
To:     netdev <>
Cc:, David Miller <>,
        Andrew Lunn <>,
        Russell King <>
Subject: Re: Request for Comment: LED device naming for netdev LEDs

On Sun, 27 Sep 2020 00:40:25 +0200
Marek Behun <> 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
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.


Powered by blists - more mailing lists