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: <1172851428.11149.140.camel@localhost.localdomain>
Date:	Fri, 02 Mar 2007 16:03:48 +0000
From:	Richard Purdie <rpurdie@...ys.net>
To:	hadi@...erus.ca
Cc:	Florian Fainelli <florian.fainelli@...-evry.fr>,
	netdev@...r.kernel.org
Subject: Re: Network activity LED trigger

On Fri, 2007-03-02 at 10:16 -0500, jamal wrote:
> 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.

We already have this API, see drivers/leds ;-)

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

We have LEDs which show up in sysfs and can be controlled by userspace
from there. They can also choose to be controlled by kernel LED
'triggers', for example. we have an IDE disk trigger which shows up
activity on IDE disks. Florian would like to see a network trigger.

The LED trigger code is quite generic and designed to have little impact
on the subsystem its added to, at least in terms of code. As always,
there will be some runtime overhead though. Ultimately it depends how
complex you make the trigger (eg. how many options it has) and where and
how you hook it into the network subsystem. I know little about the
network subsystem so this is something others will have to advise on.

Cheers,

Richard 
(LED Maintainer)

-
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