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. > work then we just use the threads/wqs that are already there. So instead > of fcoe.ko creating its threads and fnic creating its wq, libfc would > create a workqueue and we would use that. > _______________________________________________ > devel mailing list > [email protected] > http://www.open-fcoe.org/mailman/listinfo/devel _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
