Robert Love wrote: > On Fri, 2008-09-05 at 17:31 -0500, Mike Christie wrote: >> Mike Christie wrote: >>> Robert Love wrote: >>>> The following [RFC] is a mostly complete set of patches that moves >>>> gpn_id and gnn_id into fc_rport.c. They become part of the RP state >>>> machine as the first two states in the sequence of states. >>>> >>>> These patches also start the RP state machine from a work thread. >>>> >>> I do not think we should use the system work queue. If we really need to >>> create a driver wide one for this. I was wondering why we need to >>> schedule_work in some cases though? Like why does fc_ns_new_target >>> schedule the rport login instead of just doing it in that context? >>> >>> Also it looks like all drivers are going to want to queue the lport, >>> rport and ns stuff into a thread. Could we just make the >>> threading/workqueue generic code, so that if we do not need to queue >> I mean so that if we need to queue work then we just use the libfc ones. >> > We've come to the conclusion that we don't need a work queue. I got the > work threads stuck in my head because of some other stuff I was trying > to do and it started to infect this patch-set :). I'm dropping the work > queue stuff in the revision I'm working on. >
Cool. You should still probably make the threading common. One other issue is that it looks likes like for fc_lport_state_enter you want to be using del_timer_sync (if you use that then you have to modify locking so you do not hold the lport lock while holding it), or at least modify fc_lport_enter_retry so we do not hit the WARN_ON and so that on lport destruction the timer is definately killed. For the former it looks like if we transition to LPORT_ST_READY, then fc_lport_timeout grabs the lport lock then runs fc_lport_enter_retry and sees LPORT_ST_READY we will WARN_ONs. _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
