From: Pavel Machek <pavel@ucw.cz>
To: Alexander Dahl <ada@thorsis.com>
Cc: linux-leds@vger.kernel.org, Marek Behun <marek.behun@nic.cz>,
netdev <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>, Andrew Lunn <andrew@lunn.ch>,
Russell King <linux@armlinux.org.uk>,
Alexander Dahl <post@lespocky.de>
Subject: Re: Request for Comment: LED device naming for netdev LEDs
Date: Wed, 25 Nov 2020 11:59:43 +0100 [thread overview]
Message-ID: <20201125105943.GG25562@amd> (raw)
In-Reply-To: <2817077.TXCUc2rGbz@ada>
[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]
Hi!
> > > 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.
>
> I like the idea to have such a tool. What do you have in mind? Sounds for me
> like it would be somehow similar to libgpiod with gpio* for GPIO devices or
> like libevdev for input devices or like mtd-utils …
>
> Especially a userspace library could be helpful to avoid reinventing the wheel
> on userspace developer side?
>
> Does anyone else know prior work for linux leds sysfs interface from
> userspace?
I have code in tui project which accesses the LEDs from python... and
I started writing ledtool in rust.
Anyway, I agree we should provide shared library, too. Going through
the fork/exec is just too ugly.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2020-11-25 11:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-26 22:40 Request for Comment: LED device naming for netdev LEDs Marek Behun
2020-09-27 0:29 ` Andrew Lunn
2020-09-27 0:45 ` Marek Behun
2020-09-27 1:13 ` Andrew Lunn
2020-09-27 0:52 ` Marek Behun
2020-09-28 13:04 ` Alexander Dahl
2020-09-28 15:52 ` Marek Behun
2020-09-28 17:10 ` Alexander Dahl
2020-09-28 17:22 ` Marek Behun
2020-11-25 10:59 ` Pavel Machek [this message]
2020-11-25 10:57 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201125105943.GG25562@amd \
--to=pavel@ucw.cz \
--cc=ada@thorsis.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=linux-leds@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=marek.behun@nic.cz \
--cc=netdev@vger.kernel.org \
--cc=post@lespocky.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.