Date: Tue, 16 Feb 2016 13:24:15 +0000 From: Roy Marples <r...@marples.name>
I found the time to work on this, here is the patch I've been running for an hour or so upping and downing interfaces. The rule in Roy's patch is that each new state changes kicks out all higher-priority transitions, and is queued after all lower-priority transitions, with priorities DOWN = -1, UNKNOWN = 0, UP = 1. This has the effect that each queue has the regular expression down? unknown? up? with the following equivalences: down/down = down down/unknown = down/unknown down/up = down/up unknown/down = down unknown/unknown = unknown unknown/up = unknown/up up/down = down up/unknown = unknown up/up = up Except for an issue with queueing discussed privately (scheduling a softint that is already scheduled won't cause it to run again, so if_link_state_change_si needs to process the whole queue in one go), that approach looks fine to me, although as we also discussed privately we can easily compact it into a three-bit mask with a trivial update instead of a whole array of states. This has the consequence that if the link goes up/down in quick succession, and then up/down in quick succession, &c., with the queue processed after each up/down transition, userland will never be notified. However, if the link goes down/up, then down/up, &c., the userland will be notified of all the transitions. Roy claims that that's OK, and I'm inclined to believe the author of dhcpcd about this.