On Sat, Nov 22, 2008 at 08:41, Stephen Hemminger <shemminger@xxxxxxxxxx> wrote: > 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. > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ b/net/core/uevent.c 2008-11-21 13:42:13.000000000 -0800 > @@ -0,0 +1,45 @@ > +/* > + * Linux network device event notification > + switch (event) { > + case NETDEV_UNREGISTER: > + kobject_uevent(&netdev->dev.kobj, KOBJ_REMOVE); > + break; > + case NETDEV_REGISTER: > + kobject_uevent(&netdev->dev.kobj, KOBJ_ADD); > + break; Isn't UNREGISTER/REGISTER happening at the same as the device itself being created or going away? We usually do not allow any driver code to send "add/remove" events for any "struct device", because they are handled by the driver core itself. Along with the core-created events, wouldn't this create a sequence of add->add->remove->remove? This would confuse userspace tools, which can expect that an "add" will never be followed by another "add". Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html