TODO

NuttX TODO List (Last updated June 18, 2017)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This file summarizes known NuttX bugs, limitations, inconsistencies with
standards, things that could be improved, and ideas for enhancements.  This
TODO list does not include issues associated with individual boar ports. See
also the individual README.txt files in the configs/ sub-directories for
issues related to each board port.

nuttx/:

 (12)  Task/Scheduler (sched/)
  (1)  SMP
  (1)  Memory Management (mm/)
  (0)  Power Management (drivers/pm)
  (3)  Signals (sched/signal, arch/)
  (4)  pthreads (sched/pthread)
  (0)  Message Queues (sched/mqueue)
  (8)  Kernel/Protected Build
  (3)  C++ Support
  (6)  Binary loaders (binfmt/)
 (16)  Network (net/, drivers/net)
  (4)  USB (drivers/usbdev, drivers/usbhost)
  (0)  Other drivers (drivers/)
 (13)  Libraries (libc/, libm/)
 (10)  File system/Generic drivers (fs/, drivers/)
 (10)  Graphics Subsystem (graphics/)
  (3)  Build system / Toolchains
  (3)  Linux/Cywgin simulation (arch/sim)
  (4)  ARM (arch/arm/)

apps/ and other Add-Ons:

  (2)  Network Utilities (apps/netutils/)
  (1)  NuttShell (NSH) (apps/nshlib)
  (1)  System libraries apps/system (apps/system)
  (1)  Modbus (apps/modbus)
  (1)  Pascal add-on (pcode/)
  (4)  Other Applications & Tests (apps/examples/)

o Task/Scheduler (sched/)
  ^^^^^^^^^^^^^^^^^^^^^^^

  Title:       CHILD PTHREAD TERMINATION
  Description: When a tasks exits, shouldn't all of its child pthreads also be
               terminated?
  Status:      Closed.  No, this behavior will not be implemented.
  Priority:    Medium, required for good emulation of process/pthread model.
               The current behavior allows for the main thread of a task to
               exit() and any child pthreads will perist.  That does raise
               some issues:  The main thread is treated much like just-another-
               pthread but must follow the semantics of a task or a process.
               That results in some inconsistencies (for example, with robust
               mutexes, what should happen if the main thread exits while
               holding a mutex?)

  Title:       pause() NON-COMPLIANCE
  Description: In the POSIX description of this function the pause() function
               must suspend the calling thread until delivery of a signal whose
               action is either to execute a signal-catching function or to
               terminate the process.  The current implementation only waits for
               any non-blocked signal to be received.  It should only wake up if
               the signal is delivered to a handler.
  Status:      Open.
  Priority:    Medium Low.

  Title:       ON-DEMAND PAGING INCOMPLETE
  Description: On-demand paging has recently been incorporated into the RTOS.
               The design of this feature is described here:
               http://www.nuttx.org/NuttXDemandPaging.html.
               As of this writing, the basic feature implementation is
               complete and much of the logic has been verified.  The test
               harness for the feature exists only for the NXP LPC3131 (see
               configs/ea3131/pgnsh and locked directories).  There are
               some limitations of this testing so I still cannot say that
               the feature is fully functional.
  Status:      Open.  This has been put on the shelf for some time.
  Priority:    Medium-Low

  Title:       GET_ENVIRON_PTR()
  Description: get_environ_ptr() (sched/sched_getenvironptr.c) is not implemented.
               The representation of the environment strings selected for
               NuttX is not compatible with the operation.  Some significant
               re-design would be required to implement this function and that
               effort is thought to be not worth the result.
  Status:      Open.  No change is planned.
  Priority:    Low -- There is no plan to implement this.

  Title:       TIMER_GETOVERRUN()
  Description: timer_getoverrun() (sched/timer_getoverrun.c) is not implemented.
  Status:      Open
  Priority:    Low -- There is no plan to implement this.

  Title:       INCOMPATIBILITIES WITH execv() AND execl()
  Description: Simplified 'execl()' and 'execv()' functions are provided by
               NuttX.  NuttX does not support processes and hence the concept
               of overlaying a tasks process image with a new process image
               does not make any sense.  In NuttX, these functions are
               wrapper functions that:

               1. Call the non-standard binfmt function 'exec', and then
               2. exit(0).

               As a result, the current implementations of 'execl()' and
               'execv()' suffer from some incompatibilities, the most
               serious of these is that the exec'ed task will not have
               the same task ID as the vfork'ed function.  So the parent
               function cannot know the ID of the exec'ed task.
  Status:      Open
  Priority:    Medium Low for now

  Title:       ISSUES WITH atexit(), on_exit(), AND pthread_cleanup_pop()
  Description: These functions execute with the following bad properties:

               1. They run with interrupts disabled,
               2. They run in supervisor mode (if applicable), and
               3. They do not obey any setup of PIC or address
                  environments. Do they need to?
               4. In the case of task_delete() and pthread_cancel() without
                  defferred cancellation, these callbacks will run on the
                  thread of execution and address context of the caller of
                  task_delete() or pthread_cancel().  That is very bad!

               The fix for all of these issues it to have the callbacks
               run on the caller's thread as is currently done with
               signal handlers.  Signals are delivered differently in
               PROTECTED and KERNEL modes:  The deliver is involes a
               signal handling trampoline function in the user address
               space and two signal handlers:  One to call the signal
               handler trampoline in user mode (SYS_signal_handler) and
               on in with the signal handler trampoline to return to
               supervisor mode (SYS_signal_handler_return)

               The primary difference is in the location of the signal
               handling trampoline:

               - In PROTECTED mode, there is on a single user space blob
                 with a header at the beginning of the block (at a well-
                 known location.  There is a pointer to the signal handler
                 trampoline function in that header.
               - In the KERNEL mode, a special process signal handler
                 trampoline is used at a well-known location in every
                 process address space (ARCH_DATA_RESERVE->ar_sigtramp).
  Status:      Open
  Priority:    Medium Low.  This is an important change to some less
               important interfaces.  For the average user, these
               functions are just fine the way they are.

  Title:       execv() AND vfork()
  Description: There is a problem when vfork() calls execv() (or execl()) to
               start a new application:  When the parent thread calls vfork()
               it receives and gets the pid of the vforked task, and *not*
               the pid of the desired execv'ed application.

               The same tasking arrangement is used by the standard function
               posix_spawn().  However, posix_spawn uses the non-standard, internal
               NuttX interface task_reparent() to replace the child's parent task
               with the caller of posix_spawn().  That cannot be done with vfork()
               because we don't know what vfork() is going to do.

               Any solution to this is either very difficult or impossible without
               an MMU.
  Status:      Open
  Priority:    Low (it might as well be low since it isn't going to be fixed).

  Title:       errno IS NOT SHARED AMONG THREADS
  Description: In NuttX, the errno value is unique for each thread.  But for
               bug-for-bug compatibility, the same errno should be shared by
               the task and each thread that it creates.  It is *very* easy
               to make this change:  Just move the pterrno field from
               struct tcb_s to struct task_group_s.   However, I am still not
               sure if this should be done or not.
  Status:      Closed.  The existing solution is better (although its
               incompatibilities could show up in porting some code).
  Priority:    Low

  Title:       SCALABILITY
  Description: Task control information is retained in simple lists.  This
               is completely appropriate for small embedded systems where
               the number of tasks, N, is relatively small.  Most list
               operations are O(N).  This could become an issue if N gets
               very large.

               In that case, these simple lists should be replaced with
               something more performant such as a balanced tree in the
               case of ordered lists.  Fortunately, most internal lists are
               hidden behind simple accessor functions and so the internal
               data structures can be changed if need with very little impact.

               Explicitly reference to the list structure are hidden behind
               the macro this_task().

  Status:      Open
  Priority:    Low.  Things are just the way that we want them for the way
               that NuttX is used today.

  Title:       INTERNAL VERSIONS OF USER FUNCTIONS
  Description: The internal NuttX logic uses the same interfaces as does
               the application.  That sometime produces a problem because
               there is "overloaded" functionality in those user interfaces