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 open-iscsi@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to