sergiotarxz/nuttx
sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

tools/Makefile.win/unix: staging directory (and its libraries) should be removed on 'make clean' (issue noted by Dave Marples). Also updates TODO list

Browse Source
This commit is contained in:
Gregory Nutt 2018-11-06 07:37:02 -06:00
parent e748bb8cd3
commit 12a500fcb6
3 changed files with 31 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
TODO
View File

@ -1,4 +1,4 @@
NuttX TODO List (Last updated Novemer 5, 2018) NuttX TODO List (Last updated November 6, 2018)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This file summarizes known NuttX bugs, limitations, inconsistencies with This file summarizes known NuttX bugs, limitations, inconsistencies with
@ -1130,38 +1130,40 @@ o Network (net/, drivers/net)
Status: Open Status: Open
Priority: Low Priority: Low
Title: CONCURRENT TCP SEND OPERATIONS Title: CONCURRENT, UNBUFFERED TCP SEND OPERATIONS
Description: At present, there cannot be two concurrent active TCP send Description: At present, there cannot be two concurrent active TCP send
operations in progress using the same socket. This is because operations in progress using the same socket *unless*
the uIP ACK logic will support only one transfer at a time. The CONFIG_TCP_WRITE_BUFFER. This is because the uIP ACK logic
solution is simple: A mutex will be needed to make sure that each will support only one transfer at a time.
send that is started is able to be the exclusive sender until all of
the data to be sent has been ACKed.
There are probably also more reasons than just ACKs that concurrent Such a situation could occur if explicit TCP send operations
sends cannot be performed. So this probably applies to all protocols. are performed using the same socket (or dup's of the same)
For example, the tcp_conn_s structure is designed to held in a list. socket on two different threads. It can also occur implicitly
It begins with: when you execute more than one thread over and NSH Telenet
session.
struct tcp_conn_s There are two possible solutions:
{
dq_entry_t node; /* Implements a doubly linked list */
...
When the TCP socket has to wait for anything, the tcp_conn_s struct is 1. Remove option to build the network without write buffering
put into a list. If you try to put the same tcp_conn_s structure into enabled. This is is simplest and perhaps the best option.
a list twice, the list will be corrupted and the network will fail. Certainly a system can be produced with a smaller RAM
footprint without write buffering. However, that probably
does not justify permitted a crippled system.
I have not verified this, but I assume that the issue goes away if 2. Another option is to serialize the non-buffered writes for
TCP write buffering is enabled. In that case, the data is serialized a socket with a mutex. i.e., add a mutex to make sure that
in the write buffers and all issues associated with ACKs and any each send that is started is able to be the exclusive
other concurrent access issues should be eliminated. sender until all of the data to be sent has been ACKed.
That can be a very significant delay involving the send,
waiting for the ACK or a timeout and possible retransmissions!
Status: Open. There is some temporary logic to apps/nshlib that does Although it uses more memory, I believe that option 1 is the
this same fix and that temporary logic should be removed when better solution and will avoid difficult TCP bugs in the future.
send() is fixed.
Priority: Medium-Low. This is an important issue for applications that Status: Open.
send on the same TCP socket from multiple threads. Priority: Medium-Low. This is only an important issue for people who
use multi-threaded, unbuffered TCP networking without a full
understanding of the issues.
Title: POLL/SELECT ON TCP/UDP SOCKETS NEEDS READ-AHEAD Title: POLL/SELECT ON TCP/UDP SOCKETS NEEDS READ-AHEAD
Description: poll()/select() only works for availability of buffered TCP/UDP Description: poll()/select() only works for availability of buffered TCP/UDP

2
tools/Makefile.unix
View File

@ -582,6 +582,7 @@ clean: subdir_clean
$(call DELFILE, nuttx_user*) $(call DELFILE, nuttx_user*)
$(call DELFILE, .cproject) $(call DELFILE, .cproject)
$(call DELFILE, .project) $(call DELFILE, .project)
$(call DELDIR, staging)
$(call CLEAN) $(call CLEAN)
subdir_distclean: subdir_distclean:
@ -599,7 +600,6 @@ endif
$(call DELFILE, .config) $(call DELFILE, .config)
$(call DELFILE, .config.old) $(call DELFILE, .config.old)
$(call DELFILE, .gdbinit) $(call DELFILE, .gdbinit)
$(call DELDIR, staging)
# Application housekeeping targets. The APPDIR variable refers to the user # Application housekeeping targets. The APPDIR variable refers to the user
# application directory. A sample apps/ directory is included with NuttX, # application directory. A sample apps/ directory is included with NuttX,

2
tools/Makefile.win
View File

@ -565,6 +565,7 @@ clean: subdir_clean
$(call DELFILE, .gdbinit) $(call DELFILE, .gdbinit)
$(call DELFILE, .cproject) $(call DELFILE, .cproject)
$(call DELFILE, .project) $(call DELFILE, .project)
$(call DELDIR, staging)
$(call CLEAN) $(call CLEAN)
subdir_distclean: subdir_distclean:
@ -577,7 +578,6 @@ endif
$(call DELFILE, Make.defs) $(call DELFILE, Make.defs)
$(call DELFILE, .config) $(call DELFILE, .config)
$(call DELFILE, .config.old) $(call DELFILE, .config.old)
$(call DELDIR, staging)
# Application housekeeping targets. The APPDIR variable refers to the user # Application housekeeping targets. The APPDIR variable refers to the user
# application directory. A sample apps\ directory is included with NuttX, # application directory. A sample apps\ directory is included with NuttX,