[RFC]: libiscsi patch to support cxgb3i on older RHEL-5/SLES-10
Rakesh Ranjan
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
Mike Christie
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?
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).
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?
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;
}
Rakesh Ranjan
> ccing Or.
>
> 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.
Regards
Rakesh Ranjan
Mike Christie
My preference would be to integrate it into 2.6.14-23_compat.patch if it
is not too crazy, because then when I update the patches I only have to
update the one patch.
If it becomes a ifdef porting mess then two patches is ok.
Or Gerlitz
> 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?
signed, where this patch lacks both, so I can't really understand what
it is about, sorry.
Rakesh, can you resend with change log and your signature?
Or.
Mike Christie
> 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.
Mike Christie
You guys meaning, do you need iser and does Rakesh need cxgb3i?
Rakesh Ranjan
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.
Regards
Rakesh Ranjan
Or Gerlitz
> 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.
you send to James, isn't it... change log is always needed and helpful,
specifically, when you send someone an RFC, anyway, to your question
> 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.
Mike Christie
> Mike Christie wrote:
>> 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.
> Mike, signature is needed and helpful, I assume you sign all the patches
If you mean sig as in a patch description then there was one.
> you send to James, isn't it... change log is always needed and helpful,
- v1 sent initial patch.
And I do not think that tells you anything.
Mike Christie
> On 09/03/2009 07:58 AM, Or Gerlitz wrote:
>> Mike Christie wrote:
>>> 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.
>> Mike, signature is needed and helpful, I assume you sign all the patches
>
> 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?
Mike Christie
That sounded kind of jerky. I probably only meant the first part that way, because I am not sure how just a signed off helps you understand what is going on :) But the second part I was serious. If people need to work on projects that require signed offs then we can get more strict on that.
Mike Christie
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).
Rakesh Ranjan
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).
Regards
Rakesh Ranjan
Rakesh Ranjan
Hi Mike,
What happened to this patch. We need this patch upstream. If you want me
to send it again just ping me.
Regards
Rakesh Ranjan
Mike Christie
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
Rakesh Ranjan
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.
Regards
Rakesh Ranjan
Mike Christie
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.
Rakesh Ranjan
Hash: SHA1
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.
Regards
Rakesh Ranjan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJK8DKNAAoJEBqoHbxtDU4Jd/kP/A6BRK+mu93wYPmi3K1lU+Zj
kvjmDWHnLDR1d6Izq3f/z0WLR5Q2Yp1XHVH1R/m4sngU3DKv0upFJZCSmJMA8ZES
O+8B0Rtny0ko6KGlge+27Ud85GsWamWZ8T64Sr6ACR2Bx2JPO9yu3f2z4ReAH2+Q
DXHun5DORcNAv460XHfNwDmoPK8dxY+TeHRiPa1Guj/DmLd5e0xvVOmWfKHapBAH
wRRe/NyzH/9dr9PbOUBYuBtBzNraqHBjwNT5qNmBVyZ5l5BBHp8AkOKuH/QZYUFL
CPLk2NmDF8e+Oqc0ALeJIbeK4n8i8Fa0ymiFYL/8+lTr0odZX8hTY0iBUvZiLBBv
i3ZYx8chYP9p3UUOPl5/k3Aj3cqMsNm2WTCtFs5H71uzMjLw2+xAP22H8gE4YO5D
YMOEK/U0DDWtlPF+7/TVvPBSfC9npFW1PVf2tJ6ZTcp/kT6z2tb1LmIjluXIiVb3
ZPM3gkl9jtWMYwSijJoiCg8FhFdzj04z4ZPaEPazQxwPcF531wcDBVFekYH/jhVe
uqVRvHmymUT5140AawtsIDyrIjxSdH+lBSsDcUy11oDAQfxf8NWm+aHn0CKiA4I3
V9+qxAVCmoXdjPmEBM7X2gTVpk9mFlVwEzhBYCcD4gdzo55edr9GqXGgU5zuJPF3
CGpMvWyMBwzOTBuJJ7zh
=EKqG
-----END PGP SIGNATURE-----
Mike Christie
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?
Rakesh Ranjan
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.
Regards
Rakesh Ranjan
Rakesh Ranjan
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 ?
Regards
Rakesh Ranjan
Mike Christie
>
> 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 ?
>
Please rebase to what is in the open-iscsi.git tree. I just updated it
so that it has the code that will be sent for the next feature window
and what James has in his trees so it is the most uptodate.