On Wed, Feb 17, 2016 at 2:13 PM, Taylor R Campbell <campbell+netbsd-source-change...@mumble.net> wrote: > 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
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.) ozaki-r
