netdev - Re: Network activity LED trigger

lists.openwall.net		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 linux-cve-announce 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]

Message-Id: <1172848619.4845.17.camel@localhost>
Date:	Fri, 02 Mar 2007 10:16:58 -0500
From:	jamal <hadi@...erus.ca>
To:	Florian Fainelli <florian.fainelli@...-evry.fr>
Cc:	netdev@...r.kernel.org, Richard Purdie <rpurdie@...ys.net>
Subject: Re: Network activity LED trigger

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

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html