Is the intention to get this merged in upstream? If so is it useful to code that is upstream or for just a scst target? If the latter what is up with getting scst upstream?
We normally do not add code upstream for out of tree stuff. I had to remove some cxgb3i code that snuck in. Can we at least say it is useful for drivers/scsi/scsi_tgt_*.c target? That would be enough I think. On 02/11/2010 06:19 PM, Joe Eykholt wrote: > The following series implements a set of hooks and other small changes > that help when implementing an FCP target module. > > Patch 1 recodes the handling of incoming PRLIs in fc_rport_recv_prli_req() > without changing the functionality except that the incoming state check > was deleted since it was checked in the caller and some additional > length checks were added. This reduces indentation in preparation > for the next patch. > > Patch 2 adds a hook to allow FC-4 providers to have a say in the handling > of incoming PRLIs. Both an initiator (active) and a target (passive) > provider are possible for each FC-4 type from 0 to 8 (currently). > There's a provider for ELS (type 1) that handles receiving incoming ELS > requests. There's a default provider for FCP (type 8) that handles the > incoming PRLI for FCP. Type 0 PRLIs are handled as per the spec. > We don't see those in practice. Whenever a remote port is logged out > via PRLO or otherwise, a prov->prlo() call is made to the providers > that have one. The amount of code specific to targets is small. > > Patch 3 fixes a minor bug found when sending a SCSI response sequence. > > Patch 4 adds a method for setting the response handler for an exchange. > This is useful for exchanges created by the exchange manager on an > incoming request, where we expect follow-on sequences for write data. > This wouldn't necessarily need to be in the template, so let me know > if you'd rather not have it there. It might be able to be inlined > without locking if we require it only to be set once per exchange > and the arg always gets set before the function pointer. The way > I have it seems safer. > > Patch 5 adds a small array of void pointers to fc_lport for use by > passive (target) providers, indexed by FC-4 type from 0 to 8 (FCP). > > Patch 6 adds a mechanism to notify providers of changes to the set of > local ports available. Each time an lport is added or deleted a > notification chain is called. A global list of local ports is maintained > for a function that providers use to discover the ones already existing. > SCST requires this to set up /sys directories which allow configuring > the target behavior for each local port. > > Patch 7 merely adds one #define to fc_fcp.h for the task attribute field mask. > > --- > > Joe Eykholt (7): > libfc: recode incoming PRLI handling > libfc: add hook for FC-4 provider registration > libfc: fix sequence-initiative WARN in fc_seq_start_next > libfc: add method for setting handler for incoming exchange > libfc: add local port hook for provider session lookup > libfc: add hook to notify providers of local port changes > libfc: add definition for task attribute mask > > > drivers/scsi/libfc/fc_exch.c | 21 +++ > drivers/scsi/libfc/fc_libfc.c | 101 +++++++++++++++ > drivers/scsi/libfc/fc_libfc.h | 13 ++ > drivers/scsi/libfc/fc_lport.c | 65 ++++++++- > drivers/scsi/libfc/fc_rport.c | 285 > +++++++++++++++++++++++++---------------- > include/scsi/fc/fc_fcp.h | 1 > include/scsi/libfc.h | 53 +++++++- > 7 files changed, 413 insertions(+), 126 deletions(-) > _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
