I actually started the patch with this in mind - making a common layer. I was able to commonize: xx_bsg_destroy_job(), xx_bsg_jobdone(), xx_softirq_done(), a helper for the timeout function (chkjobdone()), xx_bsg_map_buffer(), xx_req_to_bsgjob(), and xx_bsg_goose_queue().
However, what I was finding was I was jumping through hoops with the data structures (whose header where, structures within structures, nested private areas, etc). Additionally, I kept finding chunks of the code flow, which had parallels to the items in the common routines, that had to be left within the transport (e.g. rx path in transport, tx in common; or vice versa) - e.g. if I can't encapsulate both sides of the code flow within the common code I lose many of the advantages - I ended up abandoning it under the guise of "complexity==bad" I can post some of the work to see if you have the same conclusion. Yes, I don't like the replication either. -- james s Mike Christie wrote: > James Smart wrote: >> This patch implements the same infrastructure as found in the FC transport >> for sgio request/response handling. >> >> The patch creates (and exports to userland) a new header - scsi_bsg_iscsi.h >> >> > > Sorry for the late reply. I am trying to sell my house and move. > > > Based on your experience with fc bsg support, do you think there is some > common code? It looks like a lot of this is generic. I just started > looking at the fc bsg stuff again, so I am not sure ATM. > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to firstname.lastname@example.org To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---