Re: [PATCH] Add a network activity LED trigger
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed, 18 Jul 2007 15:54:56 +0200 > Florian Fainelli wrote: > >> Besides missing a declaration and not linking without the network > >> LED config option, its pretty ridiculous to call this for every > >> packet just to make a led blink. > >> > > > > Could you suggest me a better way to do so ? The code was highly inspired > > from > > what is done with the IDE trigger. The declaration is done in linux/leds.h, > > which is included in dev.c for that purpose. > > > > Maybe just increment a variable and periodically check it or something > like that. Yes please, calling this millions of times per second on a high end router is just not smart. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a network activity LED trigger
Richard Purdie wrote: On Wed, 2007-07-18 at 15:54 +0200, Patrick McHardy wrote: Florian Fainelli wrote: Besides missing a declaration and not linking without the network LED config option, its pretty ridiculous to call this for every packet just to make a led blink. Could you suggest me a better way to do so ? The code was highly inspired from what is done with the IDE trigger. The declaration is done in linux/leds.h, which is included in dev.c for that purpose. Maybe just increment a variable and periodically check it or something like that. Are there not already packet counters that the LED trigger could just look at? If it did that at say 20Hz or 10Hz, it would probably look quite reasonable without impacting on the system too much The qdisc counters might work, I think all qdiscs properly maintain at least byte and packet counters. Or simply check the queue length, if > 0 there is activity. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a network activity LED trigger
On Wed, 2007-07-18 at 15:54 +0200, Patrick McHardy wrote: > Florian Fainelli wrote: > >> Besides missing a declaration and not linking without the network > >> LED config option, its pretty ridiculous to call this for every > >> packet just to make a led blink. > >> > > > > Could you suggest me a better way to do so ? The code was highly inspired > > from > > what is done with the IDE trigger. The declaration is done in linux/leds.h, > > which is included in dev.c for that purpose. > > > > Maybe just increment a variable and periodically check it or something > like that. Are there not already packet counters that the LED trigger could just look at? If it did that at say 20Hz or 10Hz, it would probably look quite reasonable without impacting on the system too much? Richard - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a network activity LED trigger
Florian Fainelli wrote: Besides missing a declaration and not linking without the network LED config option, its pretty ridiculous to call this for every packet just to make a led blink. Could you suggest me a better way to do so ? The code was highly inspired from what is done with the IDE trigger. The declaration is done in linux/leds.h, which is included in dev.c for that purpose. Maybe just increment a variable and periodically check it or something like that. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a network activity LED trigger
Hello Patrick, Le mercredi 18 juillet 2007, Patrick McHardy a écrit : > Module isn't possible, you call the led trigger from net/core/dev.c. You are right, it just occured to me. > Besides missing a declaration and not linking without the network > LED config option, its pretty ridiculous to call this for every > packet just to make a led blink. Could you suggest me a better way to do so ? The code was highly inspired from what is done with the IDE trigger. The declaration is done in linux/leds.h, which is included in dev.c for that purpose. Thank you very much for your answer. signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Add a network activity LED trigger
On Wed, 18 Jul 2007 15:27:38 +0200 Florian Fainelli <[EMAIL PROTECTED]> wrote: > Hi all, > > This patch adds a new LED trigger, based on network activity. It gathers > activity from net/core/dev.c and can be used as a LED trigger by > specifying "network-activity". Further version should allow the user to > specify the network interface to bind a LED to. This trigger is a "simple" > trigger as defined by the LED subsystem. > > Signed-off-by: Florian Fainelli <[EMAIL PROTECTED]> > -- You are slowing down the network receive path even if LED is not used. Doing mod_timer() is expensive, on a busy system you would be adding another lock roundtrip and list operation for each incoming packet. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a network activity LED trigger
Florian Fainelli wrote: > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig > index 87d2046..fdc5a8a 100644 > --- a/drivers/leds/Kconfig > +++ b/drivers/leds/Kconfig > @@ -128,5 +128,12 @@ config LEDS_TRIGGER_HEARTBEAT > load average. > If unsure, say Y. > > +config LEDS_TRIGGER_NETWORK_ACT > + tristate "LED Network Activity Trigger" Module isn't possible, you call the led trigger from net/core/dev.c. > diff --git a/net/core/dev.c b/net/core/dev.c > index ee051bb..a3a4115 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -117,6 +117,7 @@ > #include > #include > #include > +#include > > /* > * The list of packet types we will receive (as opposed to discard) > @@ -1523,6 +1524,7 @@ gso: >* stops preemption for RCU. >*/ > rcu_read_lock_bh(); > + ledtrig_network_activity(); Besides missing a declaration and not linking without the network LED config option, its pretty ridiculous to call this for every packet just to make a led blink. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add a network activity LED trigger
Hi all,
This patch adds a new LED trigger, based on network activity. It gathers
activity from net/core/dev.c and can be used as a LED trigger by
specifying "network-activity". Further version should allow the user to
specify the network interface to bind a LED to. This trigger is a "simple"
trigger as defined by the LED subsystem.
Signed-off-by: Florian Fainelli <[EMAIL PROTECTED]>
--
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 87d2046..fdc5a8a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -128,5 +128,12 @@ config LEDS_TRIGGER_HEARTBEAT
load average.
If unsure, say Y.
+config LEDS_TRIGGER_NETWORK_ACT
+ tristate "LED Network Activity Trigger"
+ depends on LEDS_TRIGGERS && NET
+ help
+ This allow LEDs to be controlled by network activity at layer-3
networking.
+ If unsure, say Y.
+
endmenu
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index aa2c18e..bc899d3 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_LEDS_COBALT) += leds-cobalt.o
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
+obj-$(CONFIG_LEDS_TRIGGER_NETWORK_ACT) += ledtrig-network-activity.o
diff --git a/drivers/leds/ledtrig-network-activity.c
b/drivers/leds/ledtrig-network-activity.c
new file mode 100644
index 000..5c2e051
--- /dev/null
+++ b/drivers/leds/ledtrig-network-activity.c
@@ -0,0 +1,63 @@
+/*
+ * LED Network Activity Trigger
+ *
+ * based on ledtrig-ide-disk by Richard Purdie
+ *
+ * Copyright 2007 Florian Fainelli <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void ledtrig_network_timerfunc(unsigned long data);
+
+DEFINE_LED_TRIGGER(ledtrig_network);
+static DEFINE_TIMER(ledtrig_network_timer, ledtrig_network_timerfunc, 0, 0);
+static int network_activity;
+static int network_lastactivity;
+
+void ledtrig_network_activity(void)
+{
+ network_activity++;
+ if (!timer_pending(&ledtrig_network_timer))
+ mod_timer(&ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+}
+EXPORT_SYMBOL(ledtrig_network_activity);
+
+static void ledtrig_network_timerfunc(unsigned long data)
+{
+ if (network_lastactivity != network_activity) {
+ network_lastactivity = network_activity;
+ led_trigger_event(ledtrig_network, LED_FULL);
+ mod_timer(&ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+ } else {
+ led_trigger_event(ledtrig_network, LED_OFF);
+ }
+}
+
+static int __init ledtrig_network_init(void)
+{
+ led_trigger_register_simple("network-activity", &ledtrig_network);
+ return 0;
+}
+
+static void __exit ledtrig_network_exit(void)
+{
+ led_trigger_unregister_simple(ledtrig_network);
+}
+
+module_init(ledtrig_network_init);
+module_exit(ledtrig_network_exit);
+
+MODULE_AUTHOR("Florian Fainelli <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("LED Network Activity trigger");
+MODULE_LICENSE("GPL");
diff --git a/net/core/dev.c b/net/core/dev.c
index ee051bb..a3a4115 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -117,6 +117,7 @@
#include
#include
#include
+#include
/*
* The list of packet types we will receive (as opposed to discard)
@@ -1523,6 +1524,7 @@ gso:
* stops preemption for RCU.
*/
rcu_read_lock_bh();
+ ledtrig_network_activity();
/* Updates of qdisc are serialized by queue_lock.
* The struct Qdisc which is pointed to by qdisc is now a
signature.asc
Description: This is a digitally signed message part.
Re: Network activity LED trigger
You know that you posted this exact message last time? ;-> And i responded here: http://marc.info/?l=linux-netdev&m=117882888105536&w=2 cheers, jamal On Wed, 2007-23-05 at 23:02 +0200, Florian Fainelli wrote: > Here comes a basic patch that adds a network led activity. It is not > configurable yet, but is enough to make a LED configured with > the "network-activity" trigger to blink on network activity. > > Netdev people can probably comment on the place of > ledtrig_network_activity(), > which is probably not adequate. Also the ledtrig_network_activity can be > network device specific for instance. > > Signed-off-by: Florian Fainelli <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Network activity LED trigger
Here comes a basic patch that adds a network led activity. It is not
configurable yet, but is enough to make a LED configured with
the "network-activity" trigger to blink on network activity.
Netdev people can probably comment on the place of ledtrig_network_activity(),
which is probably not adequate. Also the ledtrig_network_activity can be
network device specific for instance.
Signed-off-by: Florian Fainelli <[EMAIL PROTECTED]>
--
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 80acd08..25d2b58 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -127,5 +127,12 @@ config LEDS_TRIGGER_HEARTBEAT
load average.
If unsure, say Y.
+config LEDS_TRIGGER_NETWORK_ACT
+ tristate "LED Network Activity Trigger"
+ depends on LEDS_TRIGGER && NET
+ help
+ This allow LEDs to be controlled by network activity at layer-3
networking.
+ If unsure, say Y.
+
endmenu
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index aa2c18e..bc899d3 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_LEDS_COBALT) += leds-cobalt.o
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
+obj-$(CONFIG_LEDS_TRIGGER_NETWORK_ACT) += ledtrig-network-activity.o
diff --git a/drivers/leds/ledtrig-network-activity.c
b/drivers/leds/ledtrig-network-activity.c
new file mode 100644
index 000..88d17bb
--- /dev/null
+++ b/drivers/leds/ledtrig-network-activity.c
@@ -0,0 +1,61 @@
+/*
+ * LED Network Activity Trigger
+ * based on ledtrig-ide-disk by Richard Purdie
+ *
+ * Copyright 2007 Florian Fainelli <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void ledtrig_network_timerfunc(unsigned long data);
+
+DEFINE_LED_TRIGGER(ledtrig_network);
+static DEFINE_TIMER(ledtrig_network_timer, ledtrig_network_timerfunc, 0, 0);
+static int network_activity, network_lastactivity;
+
+void ledtrig_network_activity(void)
+{
+ network_activity++;
+ if (!timer_pending(&ledtrig_network_timer))
+ mod_timer(&ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+}
+EXPORT_SYMBOL(ledtrig_network_activity);
+
+static void ledtrig_network_timerfunc(unsigned long data)
+{
+ if (network_lastactivity != network_activity) {
+ network_lastactivity = network_activity;
+ led_trigger_event(ledtrig_network, LED_FULL);
+ mod_timer(&ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+ } else {
+ led_trigger_event(ledtrig_network, LED_OFF);
+ }
+}
+
+static int __init ledtrig_network_init(void)
+{
+ led_trigger_register_simple("network-activity", &ledtrig_network);
+ return 0;
+}
+
+static void __exit ledtrig_network_exit(void)
+{
+ led_trigger_unregister_simple(ledtrig_network);
+}
+
+module_init(ledtrig_network_init);
+module_exit(ledtrig_network_exit);
+
+MODULE_AUTHOR("Florian Fainelli <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("LED Network Activity trigger");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 88afcef..ed3774e 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -110,4 +110,10 @@ extern void ledtrig_ide_activity(void);
#define ledtrig_ide_activity() do {} while(0)
#endif
+#ifdef CONFIG_LEDS_TRIGGER_NETWORK_ACT
+extern void ledtrig_network_activity(void);
+#else
+#define ledtrig_network_activity() do {} while(0)
+#endif
+
#endif /* __LINUX_LEDS_H_INCLUDED */
diff --git a/net/core/dev.c b/net/core/dev.c
index 4317c1b..9423b26 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -116,6 +116,7 @@
#include
#include
#include
+#include
/*
* The list of packet types we will receive (as opposed to discard)
@@ -1451,6 +1452,8 @@ int dev_queue_xmit(struct sk_buff *skb)
gso:
spin_lock_prefetch(&dev->queue_lock);
+ ledtrig_network_activity();
+
/* Disable soft irqs for various locks below. Also
* stops preemption for RCU.
*/
pgpnSLPCKnCn3.pgp
Description: PGP signature
Re: Network activity LED trigger
On Thu, 2007-10-05 at 21:21 +0200, Florian Fainelli wrote: > Netdev people can probably comment on the place of > ledtrig_network_activity(), > which is probably not adequate. Also the ledtrig_network_activity can be > network device specific for instance. Thanks for CCing me Florian. Yes, ledtrig_network_activity() should be device specific - given the spot you have it at. Just pass dev->name for example and filter on whether the user wanted that specific device. Additionaly is there a way to sort of light different colors depending whether it is an incoming packet or outgoing? Then you can pass a hook number OUT in the case where you have ledtrig_network_activity() at the moment. This way we can add multiple hooks within the network stack. I dont remember the original patches you posted, but could you have multiple LEDs as well? cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network activity LED trigger
Hi all,
Here comes a basic patch that adds a network led activity. It is not
configurable yet, but is enough to make a LED configured with
the "network-activity" trigger to blink on network activity.
Netdev people can probably comment on the place of ledtrig_network_activity(),
which is probably not adequate. Also the ledtrig_network_activity can be
network device specific for instance.
Signed-off-by: Florian Fainelli <[EMAIL PROTECTED]>
--
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 80acd08..25d2b58 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -127,5 +127,12 @@ config LEDS_TRIGGER_HEARTBEAT
load average.
If unsure, say Y.
+config LEDS_TRIGGER_NETWORK_ACT
+ tristate "LED Network Activity Trigger"
+ depends on LEDS_TRIGGER && NET
+ help
+ This allow LEDs to be controlled by network activity at layer-3
networking.
+ If unsure, say Y.
+
endmenu
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index aa2c18e..bc899d3 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_LEDS_COBALT) += leds-cobalt.o
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
+obj-$(CONFIG_LEDS_TRIGGER_NETWORK_ACT) += ledtrig-network-activity.o
diff --git a/drivers/leds/ledtrig-network-activity.c
b/drivers/leds/ledtrig-network-activity.c
new file mode 100644
index 000..88d17bb
--- /dev/null
+++ b/drivers/leds/ledtrig-network-activity.c
@@ -0,0 +1,61 @@
+/*
+ * LED Network Activity Trigger
+ * based on ledtrig-ide-disk by Richard Purdie
+ *
+ * Copyright 2007 Florian Fainelli <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void ledtrig_network_timerfunc(unsigned long data);
+
+DEFINE_LED_TRIGGER(ledtrig_network);
+static DEFINE_TIMER(ledtrig_network_timer, ledtrig_network_timerfunc, 0, 0);
+static int network_activity, network_lastactivity;
+
+void ledtrig_network_activity(void)
+{
+ network_activity++;
+ if (!timer_pending(&ledtrig_network_timer))
+ mod_timer(&ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+}
+EXPORT_SYMBOL(ledtrig_network_activity);
+
+static void ledtrig_network_timerfunc(unsigned long data)
+{
+ if (network_lastactivity != network_activity) {
+ network_lastactivity = network_activity;
+ led_trigger_event(ledtrig_network, LED_FULL);
+ mod_timer(&ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+ } else {
+ led_trigger_event(ledtrig_network, LED_OFF);
+ }
+}
+
+static int __init ledtrig_network_init(void)
+{
+ led_trigger_register_simple("network-activity", &ledtrig_network);
+ return 0;
+}
+
+static void __exit ledtrig_network_exit(void)
+{
+ led_trigger_unregister_simple(ledtrig_network);
+}
+
+module_init(ledtrig_network_init);
+module_exit(ledtrig_network_exit);
+
+MODULE_AUTHOR("Florian Fainelli <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("LED Network Activity trigger");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 88afcef..ed3774e 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -110,4 +110,10 @@ extern void ledtrig_ide_activity(void);
#define ledtrig_ide_activity() do {} while(0)
#endif
+#ifdef CONFIG_LEDS_TRIGGER_NETWORK_ACT
+extern void ledtrig_network_activity(void);
+#else
+#define ledtrig_network_activity() do {} while(0)
+#endif
+
#endif /* __LINUX_LEDS_H_INCLUDED */
diff --git a/net/core/dev.c b/net/core/dev.c
index 4317c1b..9423b26 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -116,6 +116,7 @@
#include
#include
#include
+#include
/*
* The list of packet types we will receive (as opposed to discard)
@@ -1451,6 +1452,8 @@ int dev_queue_xmit(struct sk_buff *skb)
gso:
spin_lock_prefetch(&dev->queue_lock);
+ ledtrig_network_activity();
+
/* Disable soft irqs for various locks below. Also
* stops preemption for RCU.
*/
pgpJH7KHRnzRF.pgp
Description: PGP signature
Re: Network activity LED trigger
Florian Fainelli <[EMAIL PROTECTED]> writes: > Hi All, > > I have been talking a bit with Richard, who is the LED API maintainer, and a > LED trigger based on network activity would be something great. You should be aware that normally the kernel doesn't see all packets on a ethernet unless promiscuous mode is enabled (which it is normally not). That is because the hardware filters out all packets not for this host. A software controlled LED wouldn't be equivalent to the activity LEDs you normally have on network cards, but only show local traffic. That said if you want to get events for any in/outgoing packets you can use the same hooks as PF_PACKET uses for sniffing; using dev_add_pack with ETH_P_ALL. That will get you all incoming and outgoing packets that are local. And when someone runs tcpdump it will suddenly see all which might be unexpected. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network activity LED trigger
On Fri, 2007-02-03 at 16:03 +, Richard Purdie wrote: > On Fri, 2007-03-02 at 10:16 -0500, jamal wrote: > We already have this API, see drivers/leds ;-) Very cool ;-> I was not aware of the existence of this API. Actually i dont think it was available around 2.6.10. > 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. > This literally covers most of what i wanted; it may be too late to get rid of that user space program but it is something i see you already support;-> > 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 Well, give me pointers and i will send you a patch for a board i currently use: http://download.intel.com/design/telecom/techspec/9635.pdf which has GPIO LED. I take it i would have to write a "driver" using your API? > 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. Other people may have different opionions: I cant think of something useful from a network perspective mostly because you cant make it generic enough i.e some boards will have LEDs for their NICs and some wont. Just as some boards have activity LEDS for their IDE disks. IOW, I think general purpose LEDs will probably be very dependent on the shipping product. other than that, great work! cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network activity LED trigger
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 > > cheers, > jamal > > On Fri, 2007-02-03 at 13:58 +0100, Florian Fainelli wrote: > > Hi All, > > > > Some more thoughts. The IDE activity LED trigger is currently triggered > > when a function is called in the IDE writing/reading routines. > > > > In a similar way, we could call the trigger function in net/core/dev.c in > > netif_receive_skb and netif_rx ? > > > > I was also thinking that some network NIC already have LEDs, so it is not > > necessary for those models to "overload" the user with lights everywhere. > > > > R > > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Cordialement, Florian Fainelli - 5, rue Charles Fourier Chambre 1202 91011 Evry http://www.alphacore.net (+33) 01 60 76 64 21 (+33) 06 09 02 64 95 - Association MiNET http://www.minet.net - Institut National des Télécommunication http://www.int-evry.fr/telecomint - - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network activity LED trigger
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? cheers, jamal On Fri, 2007-02-03 at 13:58 +0100, Florian Fainelli wrote: > Hi All, > > Some more thoughts. The IDE activity LED trigger is currently triggered when > a > function is called in the IDE writing/reading routines. > > In a similar way, we could call the trigger function in net/core/dev.c in > netif_receive_skb and netif_rx ? > > I was also thinking that some network NIC already have LEDs, so it is not > necessary for those models to "overload" the user with lights everywhere. > > R - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network activity LED trigger
Hi All, Some more thoughts. The IDE activity LED trigger is currently triggered when a function is called in the IDE writing/reading routines. In a similar way, we could call the trigger function in net/core/dev.c in netif_receive_skb and netif_rx ? I was also thinking that some network NIC already have LEDs, so it is not necessary for those models to "overload" the user with lights everywhere. Regars, Florian Le jeudi 1 mars 2007, Florian Fainelli a écrit : > Hi All, > > I have been talking a bit with Richard, who is the LED API maintainer, and > a LED trigger based on network activity would be something great. > > There are somethings that concern the network stack : > > - should we specify if the network driver is allowed to contribute to > the LED activity, just like it is done for random generation, at compile > time > > - I would like to trigger the LED based on one or several network > interfaces, maybe specify via sysfs which interface triggers which LED, > and also maybe differentiate the layer-2 activity from the layer-3 > activity for instance > > - A led driver could by default be bound to a network driver, or an > interface name > > As it could be very intrusive in the network stack, you might want to > specify a bit more how you imagine a network activity trigger. > > Thanks - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Network activity LED trigger
Hi All, I have been talking a bit with Richard, who is the LED API maintainer, and a LED trigger based on network activity would be something great. There are somethings that concern the network stack : - should we specify if the network driver is allowed to contribute to the LED activity, just like it is done for random generation, at compile time - I would like to trigger the LED based on one or several network interfaces, maybe specify via sysfs which interface triggers which LED, and also maybe differentiate the layer-2 activity from the layer-3 activity for instance - A led driver could by default be bound to a network driver, or an interface name As it could be very intrusive in the network stack, you might want to specify a bit more how you imagine a network activity trigger. Thanks -- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
