Mike Christie wrote: > On 06/09/2009 12:50 PM, Benjamin Li wrote: >> Hi Rakesh, >> >> Your idea of eliminating the 'brcm_iscsiuio' daemon and integrating that >> code as a shared library into iscsid is a great idea. Just having the >> iscsid daemon to configure and run would make it easier for the end >> user. But pushing for this would be an long term goal for me because >> currently, I do not have enough free cycles to accomplish this in the >> foreseeable future. >> >> The following changes would need to occur for this idea to work: >> >> * change iscsid to recognize the new configuration options >> * eliminate the UNIX socket layer code between 'brcm_iscsiuio' and >> iscsid and replace it with new code so that the uIP could directly >> access iscsid data >> * stabilize the uIP code so that a crash/hang doesn't take down iscsid, >> also the uIP code still is changing and should be stabilized >> * continue to separate the uIP stack with hardware specific UIO code. >> * change uIP utility functions (ie. logging, wrappers) to use the >> routines provided by iscsid. >> >> I think it is a great idea, if I or someone get some time to work on >> this, I think it would make the iscsi offload solution much simpler. >> > > I like this idea too. I can help.
Hi Mike, What's your opinion about interfaces, that iscsid should provide to support uIP/vendor library scheme. I am working on this, it would be helpful to have your thoughts on it. Regards Rakesh Ranjan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
