From: jamal <hadi@cyberus.ca>
To: Florian Fainelli <florian.fainelli@int-evry.fr>
Cc: netdev@vger.kernel.org, Richard Purdie <rpurdie@rpsys.net>
Subject: Re: Network activity LED trigger
Date: Fri, 02 Mar 2007 10:16:58 -0500 [thread overview]
Message-ID: <1172848619.4845.17.camel@localhost> (raw)
In-Reply-To: <200703021516.06638.florian.fainelli@int-evry.fr>
On Fri, 2007-02-03 at 15:16 +0100, Florian Fainelli wrote:
> Hi,
>
> Le vendredi 2 mars 2007, jamal a écrit :
> > Where are these LEDs typically located? Are you talking about LEDs on a
> > network card for example? can you light them up in different colors?
>
> Those LEDS are typically controlled by GPIO lines visible in front of the
> device. It is mostly targeted to embedded devices for which you do not
> necessarily want to assign a LED to a given network interface
>
Ah, ok - ive worked with a not-so-embedded board that had something that
was accessible via the ICH; i recall writting a user-space program to
handle it. So instead of calling this just LED, probably find a more
descriptive name for it; Example GPIO-LED.
Those things are tricky to have in a generic code though, no? I.e each
chipset/board will have different address mappings on where to
read/write for a specific LED. So you need to deal with that problem
without requiring changing of the kernel every time an address changes.
I actually found exactly similar board (some manufacturer) but the
firmware was slightly different.
Heres my view of what would be useful:
Have them accessible via the kernel, but also have an API from user
space. This way user space apps can control the LED, but if i wanted to
do it from the kernel i could as well. In my case i was actually
monitoring the health of a daemon; it would show off if the daemon was
not running, green if it was happy, yellow if semi-healthy and Red if it
was in trouble.
here are some operations/messages i can see that are useful which you
probably already have in your API:
turn on LED at #x color somecolor
turn off LED at #y
query LED info at #x
dump all LEDs on board - think of this as a discovery
flicker LED at #z at frequency y color green
maybe even: "I am a wireless card with no LED, I claim LED #x"
which is matched by "tell me if anyone owns LED code"
In other words, if you just provide mechanims let people write the
policies.
This way if i wanted to tie it to my eth0 i can.
Hope that helps.
cheers,
jamal
next prev parent reply other threads:[~2007-03-02 15:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-01 21:41 Network activity LED trigger Florian Fainelli
2007-03-02 12:58 ` Florian Fainelli
2007-03-02 14:11 ` jamal
2007-03-02 14:16 ` Florian Fainelli
2007-03-02 15:16 ` jamal [this message]
2007-03-02 16:03 ` Richard Purdie
2007-03-02 16:19 ` jamal
2007-05-10 19:21 ` Florian Fainelli
2007-05-10 20:27 ` jamal
2007-03-03 2:20 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2007-05-23 21:02 Florian Fainelli
2007-05-23 22:12 ` jamal
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=1172848619.4845.17.camel@localhost \
--to=hadi@cyberus.ca \
--cc=florian.fainelli@int-evry.fr \
--cc=netdev@vger.kernel.org \
--cc=rpurdie@rpsys.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).