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 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.