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
