Date: Wed, 17 Feb 2016 11:49:48 +0900 From: Ryota Ozaki <ozak...@netbsd.org>
And the priority provides asymmetric event deliveries; when the state repeats up and down, a down event is delivered if the final state is down while a down event and a up event are delivered if the final state is up. It's confusable to me. This is the part I'm still not sure about: Roy's patch reduces up/down to just down, but leaves down/up alone. I'm guessing that Roy expects applications like dhcpcd to want to clear some state if the link ever goes down, but to be uninterested in knowing that the link went up for a microsecond and then back down again. Can we pass events as they are as much as possible? I don't complain that event reductions in the kernel, but I think it should be down based on time series manner (e.g., pick latest three events), not based on some priority things. If we accept event reductions, we can do it with bit-encoding (w/o a linked list (memory allocations)), for example represent the state as 2 bits and encode event series into a variable (say 16 events in int). 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 -- but you're probably more interested in seeing something like ...down...up than ...up/up/up.
