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

56
TODO

@ -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
@ -1130,38 +1130,40 @@ o Network (net/, drivers/net)
Status: Open
Priority: Low
Title: CONCURRENT TCP SEND OPERATIONS
Title: CONCURRENT, UNBUFFERED TCP SEND OPERATIONS
Description: At present, there cannot be two concurrent active TCP send
operations in progress using the same socket. This is because
the uIP ACK logic will support only one transfer at a time. The
solution is simple: A mutex will be needed to make sure that each
send that is started is able to be the exclusive sender until all of
the data to be sent has been ACKed.
operations in progress using the same socket *unless*
CONFIG_TCP_WRITE_BUFFER. This is because the uIP ACK logic
will support only one transfer at a time.
There are probably also more reasons than just ACKs that concurrent
sends cannot be performed. So this probably applies to all protocols.
For example, the tcp_conn_s structure is designed to held in a list.
It begins with:
Such a situation could occur if explicit TCP send operations
are performed using the same socket (or dup's of the same)
socket on two different threads. It can also occur implicitly
when you execute more than one thread over and NSH Telenet
session.
struct tcp_conn_s
{
dq_entry_t node; /* Implements a doubly linked list */
...
There are two possible solutions:
When the TCP socket has to wait for anything, the tcp_conn_s struct is
put into a list. If you try to put the same tcp_conn_s structure into
a list twice, the list will be corrupted and the network will fail.
1. Remove option to build the network without write buffering
enabled. This is is simplest and perhaps the best option.
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
TCP write buffering is enabled. In that case, the data is serialized
in the write buffers and all issues associated with ACKs and any
other concurrent access issues should be eliminated.
2. Another option is to serialize the non-buffered writes for
a socket with a mutex. i.e., add a mutex to make sure that
each send that is started is able to be the exclusive
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
this same fix and that temporary logic should be removed when
send() is fixed.
Priority: Medium-Low. This is an important issue for applications that
send on the same TCP socket from multiple threads.
Although it uses more memory, I believe that option 1 is the
better solution and will avoid difficult TCP bugs in the future.
Status: Open.
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
Description: poll()/select() only works for availability of buffered TCP/UDP

2
tools/Makefile.unix

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

2
tools/Makefile.win

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