> Attached is patch for libiscsi/libiscsi_tcp to support cxgb3i on
> RHEL-5.{,0,1,3} and SLES 10 and it applied on top of
> 2.6.14-23_compat.patch. Its based on your work for RHEL-5.4. I have run
> the regression test on mentioned platform and it worked without any
> problem. If you find it okay, then I will send the final patch with
> little bit more cleanup and needed Makefile changes.

> Regards
> Rakesh Ranjan

> 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?

> On 08/31/2009 08:15 AM, Rakesh Ranjan wrote:
>> Hi Mike,

>> Attached is patch for libiscsi/libiscsi_tcp to support cxgb3i on
>> RHEL-5.{,0,1,3} and SLES 10 and it applied on top of
>> 2.6.14-23_compat.patch. Its based on your work for RHEL-5.4. I have run
>> the regression test on mentioned platform and it worked without any
>> problem. If you find it okay, then I will send the final patch with
>> little bit more cleanup and needed Makefile changes.

>> Regards
>> Rakesh Ranjan

> I think you reverted some fixes/changes from upstream. For example the
> code below is a change I did upstream, but it did not make it into RHEL
> 5.4. You also reverted Erez's debugging stuff from upstream. You can
> check kernel.git/git to see the commits that have been done upstream
> then check if the are not present in RHEL 5.4 (I think the code in
> open-iscsi.org/kernel should be in sync with what I just send to James
> for scsi-misc/2.6.32).

> diff -Nuarp a/iscsi_tcp.c b/iscsi_tcp.c
> --- a/iscsi_tcp.c    2009-08-31 18:32:05.000000000 +0530
> +++ b/iscsi_tcp.c    2009-08-31 18:33:16.000000000 +0530
> @@ -254,6 +254,8 @@ static int iscsi_sw_tcp_xmit_segment(str

>          if (r < 0) {
>              iscsi_tcp_segment_unmap(segment);
> +            if (copied || r == -EAGAIN)
> +                break;
>              return r;
>          }
>          copied += r;
> @@ -274,17 +276,11 @@ static int iscsi_sw_tcp_xmit(struct iscs

>      while (1) {
>          rc = iscsi_sw_tcp_xmit_segment(tcp_conn, segment);
> -        /*
> -         * We may not have been able to send data because the conn
> -         * is getting stopped. libiscsi will know so propogate err
> -         * for it to do the right thing.
> -         */
> -        if (rc == -EAGAIN)
> -            return rc;
> -        else if (rc < 0) {
> +        if (rc < 0) {
>              rc = ISCSI_ERR_XMIT_FAILED;
>              goto error;
> -        } else if (rc == 0)
> +        }
> +        if (rc == 0)
>              break;

>          consumed += rc;
> @@ -465,10 +461,9 @@ static int iscsi_sw_tcp_pdu_init(struct
>                            offset, count);
>      }

> -    if (err) {
> +    if (err)
>          /* got invalid offset/len */
> -        return -EIO;
> -    }
> +        return -EINVAL;
>      return 0;
>  }

>> 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?

>> On 08/31/2009 08:15 AM, Rakesh Ranjan wrote:
>>> Hi Mike,

>>> Attached is patch for libiscsi/libiscsi_tcp to support cxgb3i on
>>> RHEL-5.{,0,1,3} and SLES 10 and it applied on top of
>>> 2.6.14-23_compat.patch. Its based on your work for RHEL-5.4. I have run
>>> the regression test on mentioned platform and it worked without any
>>> problem. If you find it okay, then I will send the final patch with
>>> little bit more cleanup and needed Makefile changes.

>>> Regards
>>> Rakesh Ranjan

>> I think you reverted some fixes/changes from upstream. For example the
>> code below is a change I did upstream, but it did not make it into RHEL
>> 5.4. You also reverted Erez's debugging stuff from upstream. You can
>> check kernel.git/git to see the commits that have been done upstream
>> then check if the are not present in RHEL 5.4 (I think the code in
>> open-iscsi.org/kernel should be in sync with what I just send to James
>> for scsi-misc/2.6.32).

> Okay I will re spin the patch against scsi-misc/2.6.32.

>> How do you plan on distributing the patch? Are you doing to intergate it
>> into the 2.6.14-23_compat.patch patch with maybe some ifdef RHEL/SLESs,
>> or are you going to add a new patch for RHEL/SLES then in the Makefile
>> figure out if we are using a RHEL/SLES kernel, or are you just going to
>> carry it yourself?

> Right now in my local tree I am using it as separate patch with Makefile
> changes to pick it up depending upon platform used. Unless you have some
> other plans, I think this approach would be good for upstream inclusion.

> 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.

>> 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.
> I am not aware to special need to support rh4 and sles9

> Or.

> For sig do you mean the Sign-off line? I do not require sigs for userspace or open-iscsi.org patches. Check out the git logs and you will see some patches have them but most do not.

> How does a signed off help you understand what the patch is doing btw? Do you need one for work/personal-preference, before you can read the patch/email description or subject?

>>>> 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

>>>>> 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

> The idea is that I can just drop in your patch over the existing
> 2.6.14-23_compat.patch compat patch right?

> cd open-iscsi/kernel
> mv your_patch 2.6.14-23_compat.patch
> make

> (the build system's patching code assumes we are in the kernel dir so I
> just have to remove the /kernel/ strings from the diff).

>>>>>> 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

>> The idea is that I can just drop in your patch over the existing
>> 2.6.14-23_compat.patch compat patch right?

>> cd open-iscsi/kernel
>> mv your_patch 2.6.14-23_compat.patch
>> make

>> (the build system's patching code assumes we are in the kernel dir so
>> I just have to remove the /kernel/ strings from the diff).

> Hi Mike,

> Yep that would work, BTW this patch applies against libiscsi of james
> tree (after copying related part, I fixed those files inclusion
> directive as to be part of open-iscsi tree).

>>>> 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

>>>>> 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

>>>>>> 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.

> 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.

>> 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?

>> 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?

> My work is based on james tree head after 2.6.31, but I can see few
> changes in 2.6.32.rcX series tree. Would you want me to re-base my work
> against current james tree ?