* 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).