lwIP - A Lightweight TCP/IP stack - Patches: patch #6250, MSG_MORE flag for send
You are not allowed to post comments on this tracker with your current authentication level.
patch #6250: MSG_MORE flag for send
Submitter: | Marc Chaland <chaland> | ||
Submitted: | Mon 29 Oct 2007 08:59:07 AM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | Done | Privacy: | Public |
Assigned to: | fbernon | Open/Closed: | Closed |
Planned Release: | 1.3.0 |
Jump to the original submission
Thu 01 Nov 2007 07:36:16 PM UTC, comment #23: |
Frédéric Bernon <fbernon> |
Thu 01 Nov 2007 06:47:16 PM UTC, comment #22: What about adding a check for known apiflags à là
|
Simon Goldschmidt <goldsimon> |
Thu 01 Nov 2007 05:39:12 PM UTC, comment #21: Ok, patch is integrated. Thank you Marc for this new feature.
|
Frédéric Bernon <fbernon> |
Thu 01 Nov 2007 12:55:17 PM UTC, comment #20: Apologies for not entering the debate earlier, but I think you've all come to the right decisions without me, so please close as fixed once the patch goes in. |
Kieran Mansley <kieranm> |
Thu 01 Nov 2007 12:28:00 PM UTC, comment #19: Looks fine! |
Simon Goldschmidt <goldsimon> |
Tue 30 Oct 2007 06:54:52 PM UTC, comment #18: Fine by me, and thankyou to Marc for his good work on it. |
Jonathan Larmour <jifl> |
Tue 30 Oct 2007 06:45:03 PM UTC, comment #17: If there is no objection, I will integrate the patch in the CVS HEAD this week.
|
Frédéric Bernon <fbernon> |
Tue 30 Oct 2007 05:00:31 PM UTC, comment #16: Patch corrected with TCP_WRITE_FLAG and sockets.h reverted.
|
Marc Chaland <chaland> |
Tue 30 Oct 2007 03:16:10 PM UTC, comment #15: TCP_WRITE_FLAG_xxx works for me. |
Jonathan Larmour <jifl> |
Tue 30 Oct 2007 01:08:54 PM UTC, comment #14: For the "defines" problem, I'm in flavor to not treat that in this item. In a first time, Marc, are you agree we put MSG_MORE=0x10 in lwip's sockets.h (even if you change them in your local copy)?
|
Frédéric Bernon <fbernon> |
Tue 30 Oct 2007 12:34:33 PM UTC, comment #13: To be clear, I think what this means is that for those in Marc's position, you should separate out functions that use lwIP socket includes into different modules from those that use uclibc socket includes.
|
Jonathan Larmour <jifl> |
Tue 30 Oct 2007 12:29:16 PM UTC, comment #12: There won't be standard values.
|
Jonathan Larmour <jifl> |
Tue 30 Oct 2007 12:14:20 PM UTC, comment #11: I just got the last uclibc from http://www.uclibc.org. I think the problem is not only MSG_ flags, but all sockets.h: I see lot of things which could cause conflicts in uclibc's "sys/socket.h" (and "bits/socket.h"), with lwip's "sockets.h".
|
Frédéric Bernon <fbernon> |
Tue 30 Oct 2007 11:43:55 AM UTC, comment #10: I don't think there is any standart values for that (but if you have some reference docs to send us, please, do it). But why uclibc headers define MSG_ flags? If they are only used by sockets API, why don't simply remove them from uclibc? That why I would like to know which other uclibc functions use them. You could also include them your "uclibc.h" file in your cc.h file. Like this, the #if (!defined...) will work. This is the same problem that ERRNO by example, or FIONREAD and FIONBIO (and some others)... |
Frédéric Bernon <fbernon> |
Tue 30 Oct 2007 11:33:36 AM UTC, comment #9: If an application uses uclibc headers for example, it will call send() with MSG_MORE=0x8000. If into lwip library, MSG_MORE=0x10, library will never detect that MSG_MORE flag has been set.
|
Marc Chaland <chaland> |
Tue 30 Oct 2007 10:49:45 AM UTC, comment #8: The problem is to know if these MSG_ defines are always used only for sockets or not. But as long they are defined like "bit-fields" on a u16_t, I don't think there will be any problems inside lwIP. Perhaps I'm wrong... |
Frédéric Bernon <fbernon> |
Tue 30 Oct 2007 10:34:49 AM UTC, comment #7:
|
Simon Goldschmidt <goldsimon> |
Tue 30 Oct 2007 09:09:28 AM UTC, comment #6:
|
Frédéric Bernon <fbernon> |
Tue 30 Oct 2007 08:52:46 AM UTC, comment #5: 1. For sockets.h, I changed values of MSG_*. In fact, many client application that I port to L4 use uclibc headers which are incompatible with sockets.h one. I already tried to remove uclibc header, but it provides some function that are not implemented into lwip library.
|
Marc Chaland <chaland> |
Mon 29 Oct 2007 08:56:50 PM UTC, comment #4: Yes, last patch seems good, except some minor things:
|
Frédéric Bernon <fbernon> |
Mon 29 Oct 2007 05:45:52 PM UTC, comment #3: I changed the patch (lwip-071029.patch) to see if I well understood what you mean.
|
Marc Chaland <chaland> |
Mon 29 Oct 2007 04:30:49 PM UTC, comment #2: [ Moving this discussion to patch from list ]
|
Jonathan Larmour <jifl> |
Mon 29 Oct 2007 09:09:10 AM UTC, comment #1: Some informations from the mailing list about this patch :
|
Frédéric Bernon <fbernon> |
Mon 29 Oct 2007 08:59:07 AM UTC, original submission:
To port lwip on L4, I need a functionnality which seems to me interesting for 1.3.0 version. This little patch has been done and tested on 1.2.0. I did a port to current CVS version. This functionnality allows to late the TCP PUSH flag.
|
Marc Chaland <chaland> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 8 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-11-01 | fbernon | Status | None | Done | |
Assigned to | None | fbernon | |||
Open/Closed | Open | Closed | |||
Planned Release | None | 1.3.0 | |||
2007-10-30 | chaland | Attached File | - | Added lwip-071030-1.patch, #14259 | |
2007-10-30 | chaland | Attached File | - | Added lwip-071030.patch, #14255 | |
2007-10-29 | chaland | Attached File | - | Added lwip-071029.patch, #14247 | |
2007-10-29 | chaland | Attached File | - | Added lwip-071026.patch, #14242 |
Powered by Savane 3.13-758e.
Corresponding source code
About the assert, if we do it here, we should do it to any function using a bit-field flag, so, I'm not in favor of add it (but no against).
About comments, I will add it...