Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Apr 2005 21:14:06 +0400
From:      Gleb Smirnoff <glebius@FreeBSD.org>
To:        Sam Leffler <sam@errno.com>
Cc:        net@FreeBSD.org
Subject:   Re: if_link_state_change() patch for review
Message-ID:  <20050419171406.GA378@cell.sick.ru>
In-Reply-To: <42652357.8020604@errno.com>
References:  <20050419064747.GC734@cell.sick.ru> <4264D430.D39B81D0@freebsd.org> <20050419120324.GA5862@cell.sick.ru> <4264F4BC.4F3B57AE@freebsd.org> <20050419121141.GB5862@cell.sick.ru> <4264F7D4.F5A9775F@freebsd.org> <42652357.8020604@errno.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 19, 2005 at 08:27:19AM -0700, Sam Leffler wrote:
S> >change message will report either all state changes or those where at
S> >the time of reporting the state changed relative to the last report.
S> >The same assumption is true for the OpenIGPd we are working on at the
S> >moment.
S>
S> It is possible with the change to defer the messages to have multiple 
S> changes coalesced.  If an app is written to assume it receives notice of 
S> every change and it uses this to track internal state then it can get 
S> confused.  The issue was whether or not to communicate any coalescing to 
S> applications so they can recognize that it's happened.  In lieu of doing 
S> that I asked for a console printf so we could see if it ever happened in 
S> practice.

Yes, all the time we are speaking about a theoretical issue. Let's see
whether it can happen or not. I decided to go ahead with this change.

S> >From an (routing) application point of view only effective state changes
S> >are interesting and only those should be provided.
S> >
S> 
S> If an inteface does down, moves network, then comes back up and you only 
S> get the up event then you will likely do the wrong thing unless you have 
S> some other way of identifying what happened.  I'm not convinced (yet) 
S> this cannot happen so am being cautious.

In this case you will receive additional messages, not only RTM_IFINFO.
Move network will also generate RTM_NEWADDR and RTM_DELADDR

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050419171406.GA378>