Mike Christie wrote:
> Rakesh Ranjan wrote:
>> Hash: SHA1
>> Mike Christie wrote:
>>> Rakesh Ranjan wrote:
>>>> Mike Christie wrote:
>>>>> Rakesh Ranjan wrote:
>>>>>> Rakesh Ranjan wrote:
>>>>>>> Mike Christie wrote:
>>>>>>>> On 09/01/2009 09:53 AM, Mike Christie wrote:
>>>>>>>>> On 09/01/2009 03:58 AM, Or Gerlitz wrote:
>>>>>>>>>> Mike Christie wrote:
>>>>>>>>>>> Or, I am ccing you because some time ago Erez was working on
>>>>>>>>>>> support
>>>>>>>>>>> for older RHEL and SLES kernels for OFED. It looks like the
>>>>>>>>>>> patch
>>>>>>>>>>> below would not be useful to you because iser is supported in
>>>>>>>>>>> those
>>>>>>>>>>> kernels, but did you guys all need RHEL 4 and maybe SLES 9
>>>>>>>>>>> support too?
>>>>>>>>>> Hi Mike, I'm used to work with patches which have a change log
>>>>>>>>>> and are
>>>>>>>>>> signed, where this patch lacks both, so I can't really
>>>>>>>>>> understand what
>>>>>>>>>> it is about, sorry.
>>>>>>>>> A signature is not going to help you understand that patch will
>>>>>>>>> it? :)
>>>>>>>>> I do not think a changelog will help either since it is the first
>>>>>>>>> version of a RFC patch.
>>>>>>>>>   From the subject of the mail and the body it looks like
>>>>>>>>> Rakesh is
>>>>>>>>> trying to port libiscsi to older distro kernels (RHEL 5 and
>>>>>>>>> SLES 10
>>>>>>>>> based) so he can support cxgb3i on them.
>>>>>>>>> I am just asking you guys if you also need RHEL 4 and SLES 9
>>>>>>>>> support.
>>>>>>>> You guys meaning, do you need iser and does Rakesh need cxgb3i?
>>>>>>> Hi Mike,
>>>>>>> Yes we do want to support cxgb3i on RHEL4/SLES9. I am sending the
>>>>>>> modified patch against current james tree's libiscsi part. This
>>>>>>> patch can replace existing 2.6.14-23_compat.patch.
>>>>>> Hi Mike,
>>>>>> Here is updated patch that fixes some MACROS to fix compilation
>>>>>> issue on RHEL5.0 and SLES10.2
>>>>> Was the patch in this mail the final version?
>>>>> What was this for:
>>>>> +#if !(defined RHELC1) && !(defined SLEC1)
>>>>>         struct delayed_work recovery_work;
>>>>> +#else
>>>>> +       struct work_struct recovery_work;
>>>>> +#endif
>>>>> And what was the reason for the ifdefs related to this for:
>>>>> +#if !(defined RHELC1) && !(defined SLEC1) \
>>>>> +       && (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,19))
>>>>>         task->have_checked_conn = false;
>>>>>         task->last_timeout = jiffies;
>>>>>         task->last_xfer = jiffies;
>>>>> +#endif
>>>> Hi Mike,
>>>> These checks I have used to preserve the original 2.6.14-23 needed
>>>> contents. Since we don't want to have separate for each different OS
>>>> release, so I just put above part with these guards.
>>> Do you need to mess with the delayed_work though? In open_iscsi_compat.h
>>> we have compat code for this:
>>> +struct delayed_work {
>>> +       struct work_struct work;
>>> +};
>>> ....
>>> and I thought this was working for RHEL kernels as well as kernel.org
>>> ones.
>>> My question for the second chunk was more why do you need to ifdef them
>>> at all? Those task fields will always be there won't they? Is it
>>> something that code is interacting with that is missing?
>>> Sorry for the late reply again.
>> Hi Mike,
>> These changes came from the .870 2.6.14-19_compat.patch mistakenly and
>> also I been thinking about RHEL4 and SLES9 support also in the same
>> patch. But right now we don't have any plan to support RHEL4/SLES9.
>> I am attaching the fixed patch. Please share your feedback on same.
> Looks ok, but what does it apply over? It fails when I try to apply it
> to the current code open-iscsi.git HEAD. Did you use a different branch
> or older head?

My patch is against james tree around 32.rcX, if you want me to send it
against current open-iscsi-head I can do that.

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