if_link_state_change() patch for review

[Gleb Smirnoff]

  Andre,

On Tue, Apr 19, 2005 at 11:49:36AM +0200, Andre Oppermann wrote:
A> > we are working on fixing LORs in if_link_state_change() path, and
A> > adding possibility to call if_link_state_change() pseudorecursively,
A> > when link of interface depends on link of the other.
A> > 
A> > I'm posting this patch for wider review. An important point about it
A> > is that, if several link events occur VERY quickly, only the last one
A> > will be processed. I don't know of any software that will be broken by
A> > such behavoir. If you know some, please tell me.
A> 
A> I assume this is per interface and not for all interfaces together.

Yes, sure.

A> You have to be careful here indeed.  If the link is rapidly flapping
A> then you only want to report changes in status.  For example when
A> it going down, up, down and all these events got queued it doesn't
A> make sense to report down->down.  This could indeed confuse some
A> tools and isn't very useful.  Either you check the first event vs.
A> the last one if there is a change in state or you just take the events
A> as trigger to have a look at the interface status when the ithread
A> runs.  There however you'd have to track the previous state to detect
A> changes.

I do not know any applications which would be confused, yet. Also, while
event coalescing is possible theoretically, I failed to reproduce it. I've
added a debugging printf, so we will see if anyone experiences these
coalescing events at all.

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