Rakesh Ranjan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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:
>>
>> +#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,19)
>> +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?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to