Date: Tue, 19 Apr 2005 16:11:41 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Andre Oppermann <andre@FreeBSD.org>, sam@FreeBSD.org Cc: net@FreeBSD.org Subject: Re: if_link_state_change() patch for review Message-ID: <20050419121141.GB5862@cell.sick.ru> In-Reply-To: <4264F4BC.4F3B57AE@freebsd.org> References: <20050419064747.GC734@cell.sick.ru> <4264D430.D39B81D0@freebsd.org> <20050419120324.GA5862@cell.sick.ru> <4264F4BC.4F3B57AE@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 19, 2005 at 02:08:28PM +0200, Andre Oppermann wrote: A> Gleb Smirnoff wrote: A> > A> You have to be careful here indeed. If the link is rapidly flapping A> > A> then you only want to report changes in status. For example when A> > A> it going down, up, down and all these events got queued it doesn't A> > A> make sense to report down->down. This could indeed confuse some A> > A> tools and isn't very useful. Either you check the first event vs. A> > A> the last one if there is a change in state or you just take the events A> > A> as trigger to have a look at the interface status when the ithread A> > A> runs. There however you'd have to track the previous state to detect A> > A> changes. A> > A> > I do not know any applications which would be confused, yet. Also, while A> > event coalescing is possible theoretically, I failed to reproduce it. I've A> > added a debugging printf, so we will see if anyone experiences these A> > coalescing events at all. A> A> It doesn't really make sense, so we better don't do it and document A> that fact. Well, the printf won't hurt anyone. And it is really interesting if this is practically possible. [cc'ing Sam, since we together have came to that printf] -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050419121141.GB5862>