* Q: netdev: generate kobject uevent on network events. @ 2009-12-09 17:02 Johannes Stezenbach 2009-12-09 18:46 ` Kay Sievers 0 siblings, 1 reply; 5+ messages in thread From: Johannes Stezenbach @ 2009-12-09 17:02 UTC (permalink / raw) To: Stephen Hemminger; +Cc: netdev, linux-hotplug Hi Stephen, about a year ago you posted a patch which allows to manage network hotplug via udev (or busybox mdev), which is useful for low-end embedded platforms that don't want to run ifplugd. http://article.gmane.org/gmane.linux.hotplug.devel/13386 The patch still works with 2.6.32. Can it get merged or were there any issues with it? It seems the discussion just stopped and the patch was forgotten... Johannes ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Q: netdev: generate kobject uevent on network events. 2009-12-09 17:02 Q: netdev: generate kobject uevent on network events Johannes Stezenbach @ 2009-12-09 18:46 ` Kay Sievers 2009-12-09 18:54 ` Benjamin LaHaise 2009-12-09 19:21 ` Dan Williams 0 siblings, 2 replies; 5+ messages in thread From: Kay Sievers @ 2009-12-09 18:46 UTC (permalink / raw) To: Johannes Stezenbach; +Cc: Stephen Hemminger, netdev, linux-hotplug On Wed, Dec 9, 2009 at 18:02, Johannes Stezenbach <js@sig21.net> wrote: > about a year ago you posted a patch which allows to manage > network hotplug via udev (or busybox mdev), which is useful > for low-end embedded platforms that don't want to run ifplugd. > > http://article.gmane.org/gmane.linux.hotplug.devel/13386 > > The patch still works with 2.6.32. Can it get merged or > were there any issues with it? It seems the discussion > just stopped and the patch was forgotten... Can't, in some setups, these events happen at a rather high frequency? I heard of people running many hundreds of ppp interfaces on a single box acting as a DSL concentrator. They state to already have trouble handling the amount of uevents generated on such boxes just for the "add/remove" events of all the interfaces if something goes wrong with the network. If we add more for state transitions, such events would probably need to be rate-limited. In general, uevents/udev are not really suitable for high-frequency events, and if such behavior can be expected, we might better stick with the current netlink interface. Thanks, Kay ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Q: netdev: generate kobject uevent on network events. 2009-12-09 18:46 ` Kay Sievers @ 2009-12-09 18:54 ` Benjamin LaHaise 2009-12-09 19:21 ` Dan Williams 1 sibling, 0 replies; 5+ messages in thread From: Benjamin LaHaise @ 2009-12-09 18:54 UTC (permalink / raw) To: Kay Sievers; +Cc: Johannes Stezenbach, Stephen Hemminger, netdev, linux-hotplug On Wed, Dec 09, 2009 at 07:46:26PM +0100, Kay Sievers wrote: > Can't, in some setups, these events happen at a rather high frequency? > I heard of people running many hundreds of ppp interfaces on a single > box acting as a DSL concentrator. /me waves Yes, DSL concentration is looking at tens of thousands to a hundred thousand interfaces on current hardware with 10G links. > They state to already have trouble > handling the amount of uevents generated on such boxes just for the > "add/remove" events of all the interfaces if something goes wrong with > the network. If we add more for state transitions, such events would > probably need to be rate-limited. In general, uevents/udev are not > really suitable for high-frequency events, and if such behavior can be > expected, we might better stick with the current netlink interface. Duplicating events in different delivery mechanisms seems pointless. A simple netlink listener can be done in less than a hundred lines, so I don't see the need for the duplication. -ben ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Q: netdev: generate kobject uevent on network events. 2009-12-09 18:46 ` Kay Sievers 2009-12-09 18:54 ` Benjamin LaHaise @ 2009-12-09 19:21 ` Dan Williams 2009-12-09 21:03 ` Johannes Stezenbach 1 sibling, 1 reply; 5+ messages in thread From: Dan Williams @ 2009-12-09 19:21 UTC (permalink / raw) To: Kay Sievers; +Cc: Johannes Stezenbach, Stephen Hemminger, netdev, linux-hotplug On Wed, 2009-12-09 at 19:46 +0100, Kay Sievers wrote: > On Wed, Dec 9, 2009 at 18:02, Johannes Stezenbach <js@sig21.net> wrote: > > about a year ago you posted a patch which allows to manage > > network hotplug via udev (or busybox mdev), which is useful > > for low-end embedded platforms that don't want to run ifplugd. > > > > http://article.gmane.org/gmane.linux.hotplug.devel/13386 > > > > The patch still works with 2.6.32. Can it get merged or > > were there any issues with it? It seems the discussion > > just stopped and the patch was forgotten... > > Can't, in some setups, these events happen at a rather high frequency? > I heard of people running many hundreds of ppp interfaces on a single > box acting as a DSL concentrator. They state to already have trouble > handling the amount of uevents generated on such boxes just for the > "add/remove" events of all the interfaces if something goes wrong with > the network. If we add more for state transitions, such events would > probably need to be rate-limited. In general, uevents/udev are not > really suitable for high-frequency events, and if such behavior can be > expected, we might better stick with the current netlink interface. And then lets direct energy towards making the netlink interface simpler for app writers. Either by fixing up libnl to be dead-simple to use, or some other mechanism. Let's fix the *actual* problem (netlink is hard to use from shell scripts) instead of creating more interfaces that work around it. Or maybe shellscripts are simply the wrong tool for this job? Dan ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Q: netdev: generate kobject uevent on network events. 2009-12-09 19:21 ` Dan Williams @ 2009-12-09 21:03 ` Johannes Stezenbach 0 siblings, 0 replies; 5+ messages in thread From: Johannes Stezenbach @ 2009-12-09 21:03 UTC (permalink / raw) To: Dan Williams; +Cc: Kay Sievers, Stephen Hemminger, netdev, linux-hotplug On Wed, Dec 09, 2009 at 11:21:26AM -0800, Dan Williams wrote: > On Wed, 2009-12-09 at 19:46 +0100, Kay Sievers wrote: > > > > Can't, in some setups, these events happen at a rather high frequency? > > I heard of people running many hundreds of ppp interfaces on a single > > box acting as a DSL concentrator. They state to already have trouble > > handling the amount of uevents generated on such boxes just for the > > "add/remove" events of all the interfaces if something goes wrong with > > the network. If we add more for state transitions, such events would > > probably need to be rate-limited. In general, uevents/udev are not > > really suitable for high-frequency events, and if such behavior can be > > expected, we might better stick with the current netlink interface. > > And then lets direct energy towards making the netlink interface simpler > for app writers. Either by fixing up libnl to be dead-simple to use, or > some other mechanism. Let's fix the *actual* problem (netlink is hard > to use from shell scripts) instead of creating more interfaces that work > around it. Or maybe shellscripts are simply the wrong tool for this > job? Hm, yeah, I liked the simplicity of the uevent patch, but I see it doesn't work for everyone. BTW, I just saw that a current busybox version (1.15+) has an iflugd applet, which uses a mix of (open coded) netlink and polling via various socket ioctls. http://git.busybox.net/busybox/tree/networking/ifplugd.c Thanks, Johannes ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-12-09 21:03 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-12-09 17:02 Q: netdev: generate kobject uevent on network events Johannes Stezenbach 2009-12-09 18:46 ` Kay Sievers 2009-12-09 18:54 ` Benjamin LaHaise 2009-12-09 19:21 ` Dan Williams 2009-12-09 21:03 ` Johannes Stezenbach
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).