On Sun, Nov 23, 2008 at 07:32, Stephen Hemminger <shemminger@xxxxxxxxxx> wrote: > On Sun, 23 Nov 2008 03:13:29 +0100 > Marcel Holtmann <marcel@xxxxxxxxxxxx> 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. >> >> 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. > 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. Sounds good! I just wanted to make sure, that we are safe here. Every other month someone comes up with the idea to pass errors, like I/O failures over uevents, which just can't scale if we have many devices, like thousands of block devices , which may all fail at the same time. The patch looks fine besides the additional "add/remove" events, which should not be send by the net core. "udevadm monitor" looks like this here: UEVENT remove /devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/eth0 (net) UEVENT remove /devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/eth0 (net) UEVENT remove /module/e1000e (module) UEVENT add /module/e1000e (module) UEVENT add /devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/eth0 (net) UEVENT add /devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/eth0 (net) If it makes things easier for possible consumers of these events, we may want to add environment variables to the event like CARRIER=0, CARRIER=1, or something that classifies the "change", or whatever else may fit here? There is kobject_uevent_env() which would accept an envp[], NULL terminated, string array. 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
