From: Dan Williams <dcbw@redhat.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Johannes Stezenbach <js@sig21.net>,
Stephen Hemminger <shemminger@vyatta.com>,
netdev@vger.kernel.org, linux-hotplug@vger.kernel.org
Subject: Re: Q: netdev: generate kobject uevent on network events.
Date: Wed, 09 Dec 2009 19:21:26 +0000 [thread overview]
Message-ID: <1260386486.28042.6.camel@localhost.localdomain> (raw)
In-Reply-To: <ac3eb2510912091046g4e5173b1sb97d6a4dddfd0b81@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dcbw@redhat.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Johannes Stezenbach <js@sig21.net>,
Stephen Hemminger <shemminger@vyatta.com>,
netdev@vger.kernel.org, linux-hotplug@vger.kernel.org
Subject: Re: Q: netdev: generate kobject uevent on network events.
Date: Wed, 09 Dec 2009 11:21:26 -0800 [thread overview]
Message-ID: <1260386486.28042.6.camel@localhost.localdomain> (raw)
In-Reply-To: <ac3eb2510912091046g4e5173b1sb97d6a4dddfd0b81@mail.gmail.com>
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
next prev parent reply other threads:[~2009-12-09 19:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-09 17:02 Q: netdev: generate kobject uevent on network events Johannes Stezenbach
2009-12-09 17:02 ` Johannes Stezenbach
2009-12-09 18:46 ` Kay Sievers
2009-12-09 18:46 ` Kay Sievers
2009-12-09 18:54 ` Benjamin LaHaise
2009-12-09 18:54 ` Benjamin LaHaise
2009-12-09 19:21 ` Dan Williams [this message]
2009-12-09 19:21 ` Dan Williams
2009-12-09 21:03 ` Johannes Stezenbach
2009-12-09 21:03 ` Johannes Stezenbach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1260386486.28042.6.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=js@sig21.net \
--cc=kay.sievers@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.