From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Williams Date: Wed, 09 Dec 2009 19:21:26 +0000 Subject: Re: Q: netdev: generate kobject uevent on network events. Message-Id: <1260386486.28042.6.camel@localhost.localdomain> List-Id: References: <20091209170251.GA11650@sig21.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Kay Sievers Cc: Johannes Stezenbach , Stephen Hemminger , netdev@vger.kernel.org, linux-hotplug@vger.kernel.org On Wed, 2009-12-09 at 19:46 +0100, Kay Sievers wrote: > On Wed, Dec 9, 2009 at 18:02, Johannes Stezenbach 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Williams Subject: Re: Q: netdev: generate kobject uevent on network events. Date: Wed, 09 Dec 2009 11:21:26 -0800 Message-ID: <1260386486.28042.6.camel@localhost.localdomain> References: <20091209170251.GA11650@sig21.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Johannes Stezenbach , Stephen Hemminger , netdev@vger.kernel.org, linux-hotplug@vger.kernel.org To: Kay Sievers Return-path: Received: from mx1.redhat.com ([209.132.183.28]:15450 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750955AbZLITVj (ORCPT ); Wed, 9 Dec 2009 14:21:39 -0500 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 2009-12-09 at 19:46 +0100, Kay Sievers wrote: > On Wed, Dec 9, 2009 at 18:02, Johannes Stezenbach 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