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.

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 
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to