Michael Hunter wrote: > On Thu, 24 Sep 2009 12:50:08 -0400 > "Anurag S. Maskey" <Anurag.Maskey at Sun.COM> wrote: > > [...] > >>> ncu_ip.c:1278-1300 What are we trying to fix and why here? We don't >>> know that there isn't something in the event stream between what is >>> currently being processed and when this will be processed that doesn't >>> need to see this ncu up. >>> >>> >> Like Alan said in his comments, if the ncu is already online when DHCP >> times out, it means that there is already an address configured for this >> NCU. So, we shouldn't be changing to offline*, timed out state. >> > > That still doesn't answer how you know what is in the event stream that > hasn't been processed that doesn't take take the ncu down. You are > comparing information from the state now to determine how to process an > event that will be operating on a possible different state. > Isn't this true for all calls to nwamd_object_set_state() and nwamd_object_set_state_timed() calls? None of these calls care for what's already in the event queue. Some of the abnormalities that we have seen in the past are related to this. We transition to a state without actually caring for what state we are currently in.
It appears that all nwamd_*_handle_state_event() should check the current state/aux_state before switching to the new state and going through the state machine. That will make our state machine a true state machine like one would draw on paper. Something like if I am in the online state, then I only care about state changes to x,y, and z and the rest are ignored. This is a separate issue though and we have handled some of these with if clauses. Anurag
