Date: Wed, 17 Feb 2016 15:12:31 +0900 From: Ryota Ozaki <ozak...@netbsd.org>
On Wed, Feb 17, 2016 at 2:13 PM, Taylor R Campbell <campbell+netbsd-source-change...@mumble.net> wrote: > Note that this queueing takes effect only if the link state changes > multiple times within maybe a few microseconds, before the softint can > run. If your link state is changing that many times so quickly, > losing an event or two is probably the least of your worries Yeah, it's nitpicking, but for that reason, I think it's better to pass events as they are to userland. > -- but > you're probably more interested in seeing something like ...down...up > than ...up/up/up. Yes. (up/up/up events are eliminated in the first place though.) So what events would you choose to skip, if not the scheme that Roy described? I bet that, whatever events you would choose to skip, we can still prove that the resulting queues need be no longer than, say, three elements, and we'd still usefully report link flapping to userland -- as long as we can make enough progress to run softints and userland processes at all. Here are some example reductions that intuitively sound reasonable to me: down/down = down up/up = up down/unknown/up = down/up down/up/down = down What other sequences of events would you simplify?