On Tue, 2008-09-09 at 10:22 -0700, Robert Love wrote: > The following series implements a change to the rport state machine and > applies a locking strategy to that state machine. > > 1) A callback function is added to the LP for RP events (READY, FAILED, LOGO) > 2) GNN_ID and GPN_ID are removed, rport state machine starts at PLOGI > - uses a dummy rport until PLOGI response > 3) A READY state is added to the RP state machine > 4) The RP state machine locking has been given a locking strategy > 5) RP only has one error/retry handling routine > 6) Naming conventions are changed > rport (remote port) = fc_rport pointer > rdata (remote port private) = fc_rport_libfc_priv pointer > > I think these patches still need a little cleaning up, but they're mostly > good. > I'm curious what everyone thinks about the folowing changes to: > > a) the locking policy > b) the event callback mechanism > c) the consolidation of fc_rport_error and fc_rport_retry. > > All comments are welcome. If there are no major issues I'll do a little > cleanup, > drop the RFC, resubmit and then commit.
I have three problems with this patch-set right now. 1. Need to delete dummy rports when there is a timeout scenario since they're not tracked by the FC transport class. 2. Should delay the retry a bit if there is a resource allocation error. 3. Can't hold locks while calling some functions. It's this last one that's going to be difficult. My problem is that I want to call fc_remote_port_add/delete while I'm holding the rport lock. Those functions expect to be called without a lock held. Also, I haven't finished the lport locking, but I expect that the event_callback function will want to lock the lport so that it can change the lport's state. In all of these cases I want to call a function while I'm holding the rport lock and those functions expect to be called without the lock held. Right now my patches drop the lock momentarily before calling one of these functions and then re-grab the lock when the function returns. This is not ideal. If I keep it this way I'd need to re-check the state once I re-grab the lock and it'll get ugly. I'm going to try and move the add/delete and event callback calls to try and avoid this problem. If anyone has any good ideas I'd love to hear them... _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
