* [PATCH net-next] bridge: add notification over netlink when STP changes state
@ 2011-05-18 15:17 Stephen Hemminger
2011-05-18 15:19 ` Ben Greear
2011-05-18 22:10 ` David Miller
0 siblings, 2 replies; 6+ messages in thread
From: Stephen Hemminger @ 2011-05-18 15:17 UTC (permalink / raw)
To: David Miller; +Cc: bridge, netdev
The first netlink code in the bridge module was to notify
user space implementations of Spanning Tree Protocol about
new ports. It did not handle the case of kernel mode STP
changing states which could be useful for monitoring.
This patch causes RTM_NEWLINK message to occur on kernel
transitions. It does not send message if request was from user
space STP, since that would cause reflection and break existing
API.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
net/bridge/br_stp.c | 4 +++-
net/bridge/br_stp_if.c | 3 +++
net/bridge/br_stp_timer.c | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
--- a/net/bridge/br_stp.c 2011-04-15 14:09:10.700851052 -0700
+++ b/net/bridge/br_stp.c 2011-05-17 10:06:09.006014826 -0700
@@ -363,6 +363,8 @@ static void br_make_blocking(struct net_
p->state = BR_STATE_BLOCKING;
br_log_state(p);
+ br_ifinfo_notify(RTM_NEWLINK, p);
+
del_timer(&p->forward_delay_timer);
}
}
@@ -386,8 +388,8 @@ static void br_make_forwarding(struct ne
p->state = BR_STATE_LEARNING;
br_multicast_enable_port(p);
-
br_log_state(p);
+ br_ifinfo_notify(RTM_NEWLINK, p);
if (br->forward_delay != 0)
mod_timer(&p->forward_delay_timer, jiffies + br->forward_delay);
--- a/net/bridge/br_stp_if.c 2011-04-15 14:09:10.700851052 -0700
+++ b/net/bridge/br_stp_if.c 2011-05-17 10:06:09.006014826 -0700
@@ -88,6 +88,7 @@ void br_stp_enable_port(struct net_bridg
br_init_port(p);
br_port_state_selection(p->br);
br_log_state(p);
+ br_ifinfo_notify(RTM_NEWLINK, p);
}
/* called under bridge lock */
@@ -104,6 +105,8 @@ void br_stp_disable_port(struct net_brid
p->topology_change_ack = 0;
p->config_pending = 0;
+ br_ifinfo_notify(RTM_NEWLINK, p);
+
del_timer(&p->message_age_timer);
del_timer(&p->forward_delay_timer);
del_timer(&p->hold_timer);
--- a/net/bridge/br_stp_timer.c 2011-04-04 09:21:25.963009153 -0700
+++ b/net/bridge/br_stp_timer.c 2011-05-17 10:06:09.018014957 -0700
@@ -97,6 +97,7 @@ static void br_forward_delay_timer_expir
netif_carrier_on(br->dev);
}
br_log_state(p);
+ br_ifinfo_notify(RTM_NEWLINK, p);
spin_unlock(&br->lock);
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net-next] bridge: add notification over netlink when STP changes state
2011-05-18 15:17 [PATCH net-next] bridge: add notification over netlink when STP changes state Stephen Hemminger
@ 2011-05-18 15:19 ` Ben Greear
2011-05-18 15:39 ` Stephen Hemminger
2011-05-18 22:10 ` David Miller
1 sibling, 1 reply; 6+ messages in thread
From: Ben Greear @ 2011-05-18 15:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, bridge, netdev
On 05/18/2011 08:17 AM, Stephen Hemminger wrote:
> The first netlink code in the bridge module was to notify
> user space implementations of Spanning Tree Protocol about
> new ports. It did not handle the case of kernel mode STP
> changing states which could be useful for monitoring.
>
> This patch causes RTM_NEWLINK message to occur on kernel
> transitions. It does not send message if request was from user
> space STP, since that would cause reflection and break existing
> API.
So one app monitoring the system won't get updates if another
app makes changes?
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net-next] bridge: add notification over netlink when STP changes state
2011-05-18 15:19 ` Ben Greear
@ 2011-05-18 15:39 ` Stephen Hemminger
2011-05-18 16:18 ` Ben Greear
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2011-05-18 15:39 UTC (permalink / raw)
To: Ben Greear; +Cc: David Miller, bridge, netdev
On Wed, 18 May 2011 08:19:40 -0700
Ben Greear <greearb@candelatech.com> wrote:
> On 05/18/2011 08:17 AM, Stephen Hemminger wrote:
> > The first netlink code in the bridge module was to notify
> > user space implementations of Spanning Tree Protocol about
> > new ports. It did not handle the case of kernel mode STP
> > changing states which could be useful for monitoring.
> >
> > This patch causes RTM_NEWLINK message to occur on kernel
> > transitions. It does not send message if request was from user
> > space STP, since that would cause reflection and break existing
> > API.
>
> So one app monitoring the system won't get updates if another
> app makes changes?
>
> Ben
For now, yes. Just don't want to break any existing users
which is more important.
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net-next] bridge: add notification over netlink when STP changes state
2011-05-18 15:39 ` Stephen Hemminger
@ 2011-05-18 16:18 ` Ben Greear
2011-05-18 23:48 ` Stephen Hemminger
0 siblings, 1 reply; 6+ messages in thread
From: Ben Greear @ 2011-05-18 16:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, bridge, netdev
On 05/18/2011 08:39 AM, Stephen Hemminger wrote:
> On Wed, 18 May 2011 08:19:40 -0700
> Ben Greear<greearb@candelatech.com> wrote:
>
>> On 05/18/2011 08:17 AM, Stephen Hemminger wrote:
>>> The first netlink code in the bridge module was to notify
>>> user space implementations of Spanning Tree Protocol about
>>> new ports. It did not handle the case of kernel mode STP
>>> changing states which could be useful for monitoring.
>>>
>>> This patch causes RTM_NEWLINK message to occur on kernel
>>> transitions. It does not send message if request was from user
>>> space STP, since that would cause reflection and break existing
>>> API.
>>
>> So one app monitoring the system won't get updates if another
>> app makes changes?
>>
>> Ben
>
> For now, yes. Just don't want to break any existing users
> which is more important.
You can get RTM_NEWLINK messages for various reasons..it would
seem a non-buggy program should have no problem dealing with one
more source.
It seems like this code is going to be inconvenient
for anyone wanting to monitor bridges using netlink, and
even if you fix it in the future, there is going to be
backwards compatible hacks that are likely to be quite
ugly!
Thanks,
Ben
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net-next] bridge: add notification over netlink when STP changes state
2011-05-18 15:17 [PATCH net-next] bridge: add notification over netlink when STP changes state Stephen Hemminger
2011-05-18 15:19 ` Ben Greear
@ 2011-05-18 22:10 ` David Miller
1 sibling, 0 replies; 6+ messages in thread
From: David Miller @ 2011-05-18 22:10 UTC (permalink / raw)
To: shemminger; +Cc: bridge, netdev
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 18 May 2011 08:17:18 -0700
> The first netlink code in the bridge module was to notify
> user space implementations of Spanning Tree Protocol about
> new ports. It did not handle the case of kernel mode STP
> changing states which could be useful for monitoring.
>
> This patch causes RTM_NEWLINK message to occur on kernel
> transitions. It does not send message if request was from user
> space STP, since that would cause reflection and break existing
> API.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
I agree with Ben that hiding events in any way is going to
be a severe limitation, long term.
I do not want to apply this and keep going down this road.
Sorry.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-05-18 23:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-05-18 15:17 [PATCH net-next] bridge: add notification over netlink when STP changes state Stephen Hemminger
2011-05-18 15:19 ` Ben Greear
2011-05-18 15:39 ` Stephen Hemminger
2011-05-18 16:18 ` Ben Greear
2011-05-18 23:48 ` Stephen Hemminger
2011-05-18 22:10 ` David Miller
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).