From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F17CC47420 for ; Mon, 28 Sep 2020 13:04:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E6AC020738 for ; Mon, 28 Sep 2020 13:04:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726651AbgI1NEU (ORCPT ); Mon, 28 Sep 2020 09:04:20 -0400 Received: from mail.thorsis.com ([92.198.35.195]:33246 "EHLO mail.thorsis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726281AbgI1NES (ORCPT ); Mon, 28 Sep 2020 09:04:18 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.thorsis.com (Postfix) with ESMTP id 555DC3D0A; Mon, 28 Sep 2020 15:04:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.thorsis.com Received: from mail.thorsis.com ([127.0.0.1]) by localhost (mail.thorsis.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8mEQwsw7i0Y; Mon, 28 Sep 2020 15:04:17 +0200 (CEST) Received: by mail.thorsis.com (Postfix, from userid 109) id 34B9C3C7F; Mon, 28 Sep 2020 15:04:16 +0200 (CEST) From: Alexander Dahl To: linux-leds@vger.kernel.org Cc: Marek Behun , netdev , David Miller , Andrew Lunn , Russell King , Alexander Dahl Subject: Re: Request for Comment: LED device naming for netdev LEDs Date: Mon, 28 Sep 2020 15:04:10 +0200 Message-ID: <2817077.TXCUc2rGbz@ada> In-Reply-To: <20200927025258.38585d5e@nic.cz> References: <20200927004025.33c6cfce@nic.cz> <20200927025258.38585d5e@nic.cz> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org Hei Marek, Am Sonntag, 27. September 2020, 02:52:58 CEST schrieb Marek Behun: > On Sun, 27 Sep 2020 00:40:25 +0200 >=20 > 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. > >=20 > > a) We could just use the interface name (eth0:yellow:activity). The > >=20 > > 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. > >=20 > > b) We could use the device name, as in struct device *. But these names > >=20 > > are often too long and may contain characters that we do not want in > > LED name (':', or '/', for example). > >=20 > > c) We could create a new naming mechanism, something like > >=20 > > device_pretty_name(dev), which some classes may implement somehow. > >=20 > > What are your ideas about this problem? > >=20 > > Marek >=20 > BTW option b) and c) can be usable if we create a new utility, ledtool, > to report infromation about LEDs and configure LEDs. >=20 > 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. I like the idea to have such a tool. What do you have in mind? Sounds for= me=20 like it would be somehow similar to libgpiod with gpio* for GPIO devices or= =20 like libevdev for input devices or like mtd-utils =E2=80=A6 Especially a userspace library could be helpful to avoid reinventing the wh= eel=20 on userspace developer side? Does anyone else know prior work for linux leds sysfs interface from=20 userspace? Greets Alex