mirror of
https://github.com/apache/nuttx.git
synced 2026-06-06 00:14:22 +08:00
SAMV7: Update floating point and TCM configuration options. Update TODO list. Update comments. Refresh a configuration
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
NuttX TODO List (Last updated December 29, 2014)
|
||||
NuttX TODO List (Last updated March 10, 2015)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This file summarizes known NuttX bugs, limitations, inconsistencies with
|
||||
@@ -10,9 +10,9 @@ nuttx/
|
||||
|
||||
(11) Task/Scheduler (sched/)
|
||||
(1) Memory Managment (mm/)
|
||||
(3) Signals (sched/, arch/)
|
||||
(2) pthreads (sched/)
|
||||
(8) Kernel/Protected Builds
|
||||
(3) Signals (sched/signal, arch/)
|
||||
(2) pthreads (sched/pthread)
|
||||
(1) Message Queues (sched/mqueue)
|
||||
(4) C++ Support
|
||||
(6) Binary loaders (binfmt/)
|
||||
(12) Network (net/, drivers/net)
|
||||
@@ -298,7 +298,7 @@ o Memory Managment (mm/)
|
||||
Priority: Medium/Low, a good feature to prevent memory leaks but would
|
||||
have negative impact on memory usage and code size.
|
||||
|
||||
o Signals (sched/, arch/)
|
||||
o Signals (sched/signal, arch/)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Title: STANDARD SIGNALS
|
||||
@@ -326,7 +326,7 @@ o Signals (sched/, arch/)
|
||||
Status: Open
|
||||
Priority: Low. Even if there are only 31 usable signals, that is still a lot.
|
||||
|
||||
o pthreads (sched/)
|
||||
o pthreads (sched/pthreads)
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
Title: CANCELLATION POINTS
|
||||
@@ -393,6 +393,25 @@ o pthreads (sched/)
|
||||
solution. So I discarded a few hours of programming. Not a
|
||||
big loss from the experience I gained."
|
||||
|
||||
Message Queues (sched/mqueue)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Title: mq_timedsend() ERROR DETECTION
|
||||
Description: mq_timedsend() will always return an error an invalid time is
|
||||
provided. However, OpenGroup.org says:
|
||||
|
||||
"Under no circumstance shall the operation fail with a timeout
|
||||
if there is sufficient room in the queue to add the message
|
||||
immediately. The validity of the abstime parameter need not be
|
||||
checked when there is sufficient room in the queue."
|
||||
|
||||
Status: Open
|
||||
Priority: Low. This is a valid POSIX compliance issue, but not thought
|
||||
to be really important in real work programming. It could
|
||||
be used to conditionally block like O_NONBLOCK by providing a
|
||||
bad time to the function. That seeks hokey and I can't think
|
||||
of any other real world use case the demands this functionality.
|
||||
|
||||
o Kernel/Protected Build
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
Reference in New Issue
Block a user