network devices generating uevents?

Perhaps the following would make it easier for applications to track network device events without having to use netlink.

Quoted 2 lines · Stephen Hemminger

Perhaps the following would make it easier for applications to track network device events without having to use netlink.

These events can not happen at a high frequency, at any time, right? We are sure that things like UP/DOWN/CHANGE can not happen at a high frequency, maybe in some failure situation?

Quoted 2 lines

Perhaps the following would make it easier for applications to track network device events without having to use netlink.

Sure, that might be useful.

These events can not happen at a high frequency, at any time, right? We are sure that things like UP/DOWN/CHANGE can not happen at a high frequency, maybe in some failure situation?

Uevents are pretty expensive, every single of them may fork a /sbin/hotplug process, or a udev event process, regardless if anybody is listening to these events or not.

We can do that only if we can be sure, that there are never things like "storms of events", which would cause a pretty high system load, and can even crash non-udev systems with out-of-memory, caused by the stateless non-managed (disabled by udev) /sbin/hotplug scripts.

Hi Kay,

Quoted 9 lines

Quoted 2 lines

Perhaps the following would make it easier for applications to track network device events without having to use netlink.

Sure, that might be useful.

These events can not happen at a high frequency, at any time, right? We are sure that things like UP/DOWN/CHANGE can not happen at a high frequency, maybe in some failure situation?

Quoted 8 lines

Uevents are pretty expensive, every single of them may fork a /sbin/hotplug process, or a udev event process, regardless if anybody is listening to these events or not.

We can do that only if we can be sure, that there are never things like "storms of events", which would cause a pretty high system load, and can even crash non-udev systems with out-of-memory, caused by the stateless non-managed (disabled by udev) /sbin/hotplug scripts.

I was looking into the same thing the other day. And just getting the interface up/down events via uevent is pretty useful. I am also interested in getting the carrier signal of Ethernet cards via a CHANGE event.

If you look at the RTNL messages, it doesn't happen that often, but the NEWLINK messages are maybe a little bit too much and we should restrict it to event that really matter. So up/down are user triggered event normally. So that should be safe. I would be a little bit worried about the CHANGE event. Here we might wanna restrict it to a subset of possible changes inside the network device.

Regards

Marcel

Quoted 23 lines · On Sun, 23 Nov 2008 03:13:29 +0100 Marcel Holtmann <[email protected]> wrote:

Quoted 9 lines

Quoted 2 lines

Perhaps the following would make it easier for applications to track network device events without having to use netlink.

Sure, that might be useful.

These events can not happen at a high frequency, at any time, right? We are sure that things like UP/DOWN/CHANGE can not happen at a high frequency, maybe in some failure situation?

Quoted 8 lines

Uevents are pretty expensive, every single of them may fork a /sbin/hotplug process, or a udev event process, regardless if anybody is listening to these events or not.

We can do that only if we can be sure, that there are never things like "storms of events", which would cause a pretty high system load, and can even crash non-udev systems with out-of-memory, caused by the stateless non-managed (disabled by udev) /sbin/hotplug scripts.

I was looking into the same thing the other day. And just getting the interface up/down events via uevent is pretty useful. I am also interested in getting the carrier signal of Ethernet cards via a CHANGE event.

Quoted 6 lines

If you look at the RTNL messages, it doesn't happen that often, but the NEWLINK messages are maybe a little bit too much and we should restrict it to event that really matter. So up/down are user triggered event normally. So that should be safe. I would be a little bit worried about the CHANGE event. Here we might wanna restrict it to a subset of possible changes inside the network device.

The events are carrier events are sampled by the linkwatch mechanism already, to eliminate too active bouncing. The other events only happen when administrator does something like add new device or take it on/off line.

It is easier for some applications to deal with text based interfaces like uevent, rather than using netlink to listen for events.

Note, this does not deal with network namespaces but that is a generic problem that already exists with kobjects (see rename events).

Signed-off-by Stephen Hemminger <[email protected]>

---
 net/core/Makefile |    1
 net/core/uevent.c |   61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 62 insertions(+)

net/core/Makefile 2008-11-24 08:51:01.000000000 -0800 renamed from net/core/Makefile 2008-11-24 08:40:10.000000000 -0800 +1 -0

@@ -17,3 +17,4 @@ obj-$(CONFIG_NET_PKTGEN) += pktgen.o
 obj-$(CONFIG_NETPOLL) += netpoll.o
 obj-$(CONFIG_NET_DMA) += user_dma.o
 obj-$(CONFIG_FIB_RULES) += fib_rules.o
+obj-$(CONFIG_HOTPLUG) += uevent.o

net/core/uevent.c 2008-11-24 09:06:50.000000000 -0800 renamed from dev/null 1970-01-01 00:00:00.000000000 +0000 +17 -0

@@ -0,0 +1,60 @@
+/*
+ * Linux network device event notification
+ *
+ * Author:
+ *     Stephen Hemminger <[email protected]>
+ */
+
+#include <linux/kernel.h>
+#include <linux/netdevice.h>
+#include <linux/kobject.h>
+#include <linux/notifier.h>
+
+/*
+ * Generate uevent in response to nework device changes.
+ * NB: KOBJ_MOVE is already genereated by kobject_rename
+ */
+static int netdev_event(struct notifier_block *this, unsigned long event, void *ptr)

Quoted 40 lines · Stephen Hemminger

It is easier for some applications to deal with text based interfaces like uevent, rather than using netlink to listen for events.

Note, this does not deal with network namespaces but that is a generic problem that already exists with kobjects (see rename events).

Signed-off-by Stephen Hemminger <[email protected]>

---
 net/core/Makefile |    1
 net/core/uevent.c |   61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 62 insertions(+)

net/core/Makefile 2008-11-24 08:51:01.000000000 -0800 renamed from net/core/Makefile 2008-11-24 08:40:10.000000000 -0800 +1 -0

@@ -17,3 +17,4 @@ obj-$(CONFIG_NET_PKTGEN) += pktgen.o
 obj-$(CONFIG_NETPOLL) += netpoll.o
 obj-$(CONFIG_NET_DMA) += user_dma.o
 obj-$(CONFIG_FIB_RULES) += fib_rules.o
+obj-$(CONFIG_HOTPLUG) += uevent.o

net/core/uevent.c 2008-11-24 09:06:50.000000000 -0800 renamed from dev/null 1970-01-01 00:00:00.000000000 +0000 +17 -0

@@ -0,0 +1,60 @@
+/*
+ * Linux network device event notification
+ *
+ * Author:
+ *     Stephen Hemminger <[email protected]>
+ */
+
+#include <linux/kernel.h>
+#include <linux/netdevice.h>
+#include <linux/kobject.h>
+#include <linux/notifier.h>
+
+/*
+ * Generate uevent in response to nework device changes.
+ * NB: KOBJ_MOVE is already genereated by kobject_rename
+ */
+static int netdev_event(struct notifier_block *this, unsigned long event, void *ptr)

net/core/uevent.c 2008-11-24 09:06:50.000000000 -0800 line 27

Quoted 10 lines

net/core/uevent.c 2008-11-24 09:06:50.000000000 -0800 renamed from dev/null 1970-01-01 00:00:00.000000000 +0000 +10 -0

+{
+       struct net_device *netdev = ptr;
+
+       switch (event) {
+       case NETDEV_UNREGISTER:
+               kobject_uevent(&netdev->dev.kobj, KOBJ_REMOVE);
+               break;
+       case NETDEV_REGISTER:
+               kobject_uevent(&netdev->dev.kobj, KOBJ_ADD);
+               break;

Did you do anything else to prevent the duplicated add/remove events? The core does send these already. I replied with a "udevadm monitor" output to your earlier mail. Don't you see the duplicates on your box?

Thanks,
Kay

Quoted 6 lines · On Mon, 24 Nov 2008 20:55:02 +0100 "Kay Sievers" <[email protected]> wrote:

Did you do anything else to prevent the duplicated add/remove events? The core does send these already. I replied with a "udevadm monitor" output to your earlier mail. Don't you see the duplicates on your box?

Thanks,
Kay

okay, then i'll just take it out of here.

net/core/uevent.c new file +4 -0

+	case NETDEV_CHANGE:
+		if (netif_running(netdev)) {
+			char str[64] = "DEVSTATE=UP";
+			char *envp[2] = { str, NULL };

It is easier for some applications to deal with text based interfaces like uevent, rather than using netlink to listen for events.

Note, this does not deal with network namespaces but that is a generic problem that already exists with kobjects (see rename events).

Signed-off-by Stephen Hemminger <[email protected]>

It is easier for some applications to deal with text based interfaces like uevent, rather than using netlink to listen for events.

Note, this does not deal with network namespaces but that is a generic problem that already exists with kobjects (see rename events).

Signed-off-by Stephen Hemminger <[email protected]>

---
net/core/Makefile | 1
net/core/uevent.c | 61 ++++++++++++++++++++++++++++++++++++++++++++
++++++++++

2 files changed, 62 insertions(+)

net/core/Makefile +0 -0

@@ -17,3 +17,4 @@ obj-$(CONFIG_NET_PKTGEN) += pktgen.o

obj-$(CONFIG_NETPOLL) += netpoll.o
obj-$(CONFIG_NET_DMA) += user_dma.o
obj-$(CONFIG_FIB_RULES) += fib_rules.o

net/core/Makefile +1 -0

+obj-$(CONFIG_HOTPLUG) += uevent.o

net/core/uevent.c new file +17 -0

@@ -0,0 +1,55 @@
+/*
+ * Linux network device event notification
+ *
+ * Author:
+ *	Stephen Hemminger <[email protected]>
+ */
+
+#include <linux/kernel.h>
+#include <linux/netdevice.h>
+#include <linux/kobject.h>
+#include <linux/notifier.h>
+
+/*
+ * Generate uevent in response to network device state changes.
+ * Other events are already handled by device subsystem.
+ */
+static int netdev_event(struct notifier_block *this, unsigned long  

event, void *ptr)

net/core/uevent.c new file +14 -0

+{
+	struct net_device *netdev = ptr;
+
+	switch (event) {
+	case NETDEV_UP:
+		kobject_uevent(&netdev->dev.kobj, KOBJ_ONLINE);
+		break;
+
+	case NETDEV_DOWN:
+		kobject_uevent(&netdev->dev.kobj, KOBJ_OFFLINE);
+		break;
+
+	case NETDEV_CHANGE: {
+		char str[64] = "DEVSTATE=UP";

Hi Stephen,

Quoted 56 lines

It is easier for some applications to deal with text based interfaces like uevent, rather than using netlink to listen for events.

Note, this does not deal with network namespaces but that is a generic problem that already exists with kobjects (see rename events).

Signed-off-by Stephen Hemminger <[email protected]>

---
net/core/Makefile | 1
net/core/uevent.c | 61 ++++++++++++++++++++++++++++++++++++++++++++
++++++++++

2 files changed, 62 insertions(+)

net/core/Makefile +0 -0

@@ -17,3 +17,4 @@ obj-$(CONFIG_NET_PKTGEN) += pktgen.o

obj-$(CONFIG_NETPOLL) += netpoll.o
obj-$(CONFIG_NET_DMA) += user_dma.o
obj-$(CONFIG_FIB_RULES) += fib_rules.o

net/core/Makefile +1 -0

+obj-$(CONFIG_HOTPLUG) += uevent.o

net/core/uevent.c new file +17 -0

@@ -0,0 +1,55 @@
+/*
+ * Linux network device event notification
+ *
+ * Author:
+ *	Stephen Hemminger <[email protected]>
+ */
+
+#include <linux/kernel.h>
+#include <linux/netdevice.h>
+#include <linux/kobject.h>
+#include <linux/notifier.h>
+
+/*
+ * Generate uevent in response to network device state changes.
+ * Other events are already handled by device subsystem.
+ */
+static int netdev_event(struct notifier_block *this, unsigned long  

event, void *ptr)

net/core/uevent.c new file +14 -0

+{
+	struct net_device *netdev = ptr;
+
+	switch (event) {
+	case NETDEV_UP:
+		kobject_uevent(&netdev->dev.kobj, KOBJ_ONLINE);
+		break;
+
+	case NETDEV_DOWN:
+		kobject_uevent(&netdev->dev.kobj, KOBJ_OFFLINE);
+		break;
+
+	case NETDEV_CHANGE: {
+		char str[64] = "DEVSTATE=UP";

net/core/uevent.c line 41

Quoted 10 lines

net/core/uevent.c new file +10 -0

+		char *envp[2] = { str, NULL };
+
+		if (netif_oper_up(netdev))
+			strcat(str, ",RUNNING");
+		if (netif_carrier_ok(netdev))
+			strcat(str, ",LOWER_UP");
+		if (netif_dormant(netdev))
+			strcat(str, ",DORMANT");
+		kobject_uevent_env(&netdev->dev.kobj, KOBJ_CHANGE, envp);
+		break;

do we wanna copy just what ifconfig shows or do we might be a more intelligent and have separate variables like RUNNING=1 etc.?

Regards

Marcel

Quoted 7 lines · On Tue, 25 Nov 2008 04:51:53 +0100 Marcel Holtmann <[email protected]> wrote:

Quoted 7 lines

It is easier for some applications to deal with text based interfaces like uevent, rather than using netlink to listen for events.

Note, this does not deal with network namespaces but that is a generic problem that already exists with kobjects (see rename events).

Signed-off-by Stephen Hemminger <[email protected]>

Quoted 2 lines

do we wanna copy just what ifconfig shows or do we might be a more intelligent and have separate variables like RUNNING=1 etc.?

Was arbitrary choice to just use same flags as existing ifconfig. What ever feels best I guess...

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

It is easier for some applications to deal with text based interfaces
like uevent, rather than using netlink to listen for events.

Note, this does not deal with network namespaces but that is a generic
problem that already exists with kobjects (see rename events).

Signed-off-by Stephen Hemminger <[email protected]>

...

Quoted 5 lines

Quoted 2 lines

do we wanna copy just what ifconfig shows or do we might be a more intelligent and have separate variables like RUNNING=1 etc.?

Was arbitrary choice to just use same flags as existing ifconfig. What ever feels best I guess...

So what do folks want me to do here? Should I put Stephen's latest patch in, or do we want to make some kind of flags change?

Quoted 14 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

It is easier for some applications to deal with text based interfaces like uevent, rather than using netlink to listen for events.

Note, this does not deal with network namespaces but that is a generic problem that already exists with kobjects (see rename events).

Signed-off-by Stephen Hemminger <[email protected]>

...

Quoted 5 lines

Quoted 2 lines

do we wanna copy just what ifconfig shows or do we might be a more intelligent and have separate variables like RUNNING=1 etc.?

Was arbitrary choice to just use same flags as existing ifconfig. What ever feels best I guess...

Quoted 2 lines

So what do folks want me to do here? Should I put Stephen's latest patch in, or do we want to make some kind of flags change?

I am thinking of using per value variables. My personal choice.

Kay, any pointers or opinions from you?