TODO

NuttX TODO List (Last updated November 27, 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/)
  (2)  pthreads (sched/pthread)
  (0)  Message Queues (sched/mqueue)
  (8)  Kernel/Protected Build
  (3)  C++ Support
  (6)  Binary loaders (binfmt/)
 (17)  Network (net/, drivers/net)
  (4)  USB (drivers/usbdev, drivers/usbhost)
  (0)  Other drivers (drivers/)
 (12)  Libraries (libc/, libm/)
 (10)  File system/Generic drivers (fs/, drivers/)
 (10)  Graphics Subsystem (graphics/)
  (1)  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
               that are not desireable.

               For example, having cancellation points hidden inside of the
               OS can cause non-cancellation point interfaces to behave
               strangely.

               Here is another issue:  Internal OS functions should not set
               errno and should never have to look at the errno value to
               determine the cause of the failure.  The errno is provided
               for compatibility with POSIX application interface
               requirements and really doesn't need to be used within the
               OS.

               Both of these could be fixed if there were special internal
               versions these functions.  For example, there could be a an
               nxsem_wait() that does all of the same things as sem_wait()
               was does not create a cancellation point and does not set
               the errno value on failures.

               Everything inside the OS would use nx_sem_wait().
               Applications would call sem_wait() which would just be a
               wrapper around nx_sem_wait() that adds the cancellation point
               and that sets the errno value on failures.

               On particularly difficult issue is the use of common memory
               manager C, and NX libraries in the build.  For the FLAT
               build, that is not such a issue because the OS internal
               versions of the interfaces can be used.  But is a difficult
               problem for PROTECTED and KERNEL builds where the OS links
               with a different version of the libraries than does the
               application:  The OS version would use the OS internal
               interfaces and the application would use the standard
               interfaces.

               But that raises yet another issue:  If the application
               version of the libraries use the standard interfaces
               internally, then they may generate unexpected cancellation
               points.  For example, the memory management would take a
               semaphore using sem_wait() to get exclusive access to the
               heap.  That means that every call to malloc() and free()
               would be a cancellation point, a clear POSIX violation.

               Changes like that could clean up some of this internal
               craziness.

               UPDATE:
               2017-10-03:  This change has been completed for the case of
                 semaphores used in the OS.  Still need to checkout signals
                 and messages queues that are also used in the OS.  Also
                 backed out commit b4747286b19d3b15193b2a5e8a0fe48fa0a8638c.
               2017-10-06:  This change has been completed for the case of
                 signals used in the OS.  Still need to checkout messages
                 queues that are also used in the OS.
               2017-10-10:  This change has been completed for the case of
                 message queue used in the OS.  I am keeping this issue
                 open because (1) there are some known remaining calls that
                 that will modify the errno (such as dup(), dup2(),
                 sched_getparam(), sched_reprioritize(). sched_setaffinity(),
                 task_activate(), mq_open(), mq_close(), and others) and (2)
                 there may still be calls that create cancellation points.
                 Need to check things like open(), close(), read(), write(),
                 and possibly others.

  Status:      Open
  Priority:    Low.  Things are working OK the way they are.  But the design
               could be improved and made a little more efficient with this
               change.

  Task:        IDLE THREAD TCB SETUP
  Description: There are issues with setting IDLE thread stacks:

               1. One problem is stack-related data in the IDLE threads TCB.
                  A solution might be to standardize the use of g_idle_topstack.
                  That you could add initialization like this in os_start:

                  @@ -344,6 +347,11 @@ void os_start(void)
                     g_idleargv[1]  = NULL;
                     g_idletcb.argv = g_idleargv;

                  +  /* Set the IDLE task stack size */
                  +
                  +  g_idletcb.cmn.adj_stack_size = CONFIG_IDLETHREAD_STACKSIZE;
                  +  g_idletcb.cmn.stack_alloc_ptr = (void *)(g_idle_topstack - CONFIG_IDLETHREAD_STACKSIZE);
                  +
                     /* Then add the idle task's TCB to the head of the ready to run list */

                     dq_addfirst((FAR dq_entry_t *)&g_idletcb, (FAR dq_queue_t *)&g_readytorun);

                  The g_idle_topstack variable is available for almost all architectures:

                  $ find . -name *.h | xargs grep g_idle_top
                  ./arm/src/common/up_internal.h:EXTERN const uint32_t g_idle_topstack;
                  ./avr/src/avr/avr.h:extern uint16_t g_idle_topstack;
                  ./avr/src/avr32/avr32.h:extern uint32_t g_idle_topstack;
                  ./hc/src/common/up_internal.h:extern uint16_t g_idle_topstack;
                  ./mips/src/common/up_internal.h:extern uint32_t g_idle_topstack;
                  ./misoc/src/lm32/lm32.h:extern uint32_t g_idle_topstack;
                  ./renesas/src/common/up_internal.h:extern uint32_t g_idle_topstack;
                  ./renesas/src/m16c/chip.h:extern uint32_t g_idle_topstack; /* Start of the heap */
                  ./risc-v/src/common/up_internal.h:EXTERN uint32_t g_idle_topstack;
                  ./x86/src/common/up_internal.h:extern uint32_t g_idle_topstack;

                  That omits these architectures: sh1, sim, xtensa, z16, z80,
                  ez80, and z8.  All would have to support this common
                  globlal variable.

                  Also, the stack itself may be 8-, 16-, or 32-bits wide,
                  depending upon the architecture and do have differing
                  alignment requirements.

               2. Another problem is colorizing that stack to use with
                 stack usage monitoring logic.  There is logic in some
                 start functions to do this in a function called go_os_start.
                 It is available in these architectures:

                 ./arm/src/efm32/efm32_start.c:static void go_os_start(void *pv, unsigned int nbytes)
                 ./arm/src/kinetis/kinetis_start.c:static void go_os_start(void *pv, unsigned int nbytes)
                 ./arm/src/sam34/sam_start.c:static void go_os_start(void *pv, unsigned int nbytes)
                 ./arm/src/samv7/sam_start.c:static void go_os_start(void *pv, unsigned int nbytes)
                 ./arm/src/stm32/stm32_start.c:static void go_os_start(void *pv, unsigned int nbytes)
                 ./arm/src/stm32f7/stm32_start.c:static void go_os_start(void *pv, unsigned int nbytes)
                 ./arm/src/stm32l4/stm32l4_start.c:static void go_os_start(void *pv, unsigned int nbytes)
                 ./arm/src/tms570/tms570_boot.c:static void go_os_start(void *pv, unsigned int nbytes)
                 ./arm/src/xmc4/xmc4_start.c:static void go_os_start(void *pv, unsigned int nbytes)

                 But no others.
  Status:     Open
  Priority:   Low, only needed for more complete debug.

o SMP
  ^^^

  Title:       SMP AND DATA CACHES
  Description: When spinlocks, semaphores, etc. are used in an SMP system with
               a data cache, then there may be problems with cache coherency
               in some CPU architectures:  When one CPU modifies the shared
               object, the changes may not be visible to another CPU if it
               does not share the data cache. That would cause failure in
               the IPC logic.

               Flushing the D-cache on writes and invalidating before a read is
               not really an option.  That would essentially effect every memory
               access and there may be side-effects due to cache line sizes
               and alignment.

               For the same reason a separate, non-cacheable memory region is
               not an option.  Essentially all data would have to go in the
               non-cached region and you would have no benefit from the data
               cache.

               On ARM Cortex-A, each CPU has a separate data cache.  However,
               the MPCore's Snoop Controller Unit supports coherency among
               the different caches.  The SCU is enabled by the SCU control
               register and each CPU participates in the SMP coherency by
               setting the ACTLR_SMP bit in the auxiliary control register
               (ACTLR).

  Status:      Closed
  Priority:    High on platforms that may have the issue.

o Memory Management (mm/)
  ^^^^^^^^^^^^^^^^^^^^^^^

  Title:       FREE MEMORY ON TASK EXIT
  Description: Add an option to free all memory allocated by a task when the
               task exits. This is probably not be worth the overhead for a
               deeply embedded system.

               There would be complexities with this implementation as well
               because often one task allocates memory and then passes the
               memory to another:  The task that "owns" the memory may not
               be the same as the task that allocated the memory.

               Update.  From the NuttX forum:
               ...there is a good reason why task A should never delete task B.
               That is because you will strand memory resources. Another feature
               lacking in most flat address space RTOSs is automatic memory
               clean-up when a task exits.

               That behavior just comes for free in a process-based OS like Linux:
               Each process has its own heap and when you tear down the process
               environment, you naturally destroy the heap too.

               But RTOSs have only a single, shared heap. I have spent some time
               thinking about how you could clean up memory required by a task
               when a task exits. It is not so simple. It is not as simple as
               just keeping memory allocated by a thread in a list then freeing
               the list of allocations when the task exists.

               It is not that simple because you don't know how the memory is
               being used. For example, if task A allocates memory that is used
               by task B, then when task A exits, you would not want to free that
               memory needed by task B. In a process-based system, you would
               have to explicitly map shared memory (with reference counting) in
               order to share memory. So the life of shared memory in that
               environment is easily managed.

               I have thought that the way that this could be solved in NuttX
               would be: (1) add links and reference counts to all memory allocated
               by a thread. This would increase the memory allocation overhead!
               (2) Keep the list head in the TCB, and (3) extend mmap() and munmap()
               to include the shared memory operations (which would only manage
               the reference counting and the life of the allocation).

               Then what about pthreads? Memory should not be freed until the last
               pthread in the group exists. That could be done with an additional
               reference count on the whole allocated memory list (just as streams
               and file descriptors are now shared and persist until the last
               pthread exits).

               I think that would work but to me is very unattractive and
               inconsistent with the NuttX "small footprint" objective. ...

               Other issues:
               - Memory free time would go up because you would have to remove
                 the memory from that list in free().
               - There are special cases inside the RTOS itself.  For example,
                 if task A creates task B, then initial memory allocations for
                 task B are created by task A.  Some special allocators would
                 be required to keep this memory on the correct list (or on
                 no list at all).

               Updated 2016-06-25:
               For processors with an MMU (Memory Management Unit), NuttX can be
               built in a kernel mode.  In that case, each process will have a
               local copy of its heap (filled with sbrk()) and when the process
               exits, its local heap will be destroyed and the underlying page
               memory is recovered.

               So in this case, NuttX work just link Linux or or *nix systems:
               All memory allocated by processes or threads in processes will
               be recovered when the process exits.

               But not for the flat memory build.  In that case, the issues
               above do apply.  There is no safe way to recover the memory in
               that case (and even if there were, the additional overhead would
               not be acceptable on most platforms).

               This does not prohibit anyone from creating a wrapper for malloc()
               and an atexit() callback that frees memory on task exit.  People
               are free and, in fact, encouraged, to do that.  However, since
               it is inherently unsafe, I would never incorporate anything
               like that into NuttX.

  Status:      Open.  No changes are planned.  NOTE: This applies to the FLAT
               and PROTECTED builds only.  There is no such leaking of memory
               in the KERNEL build mode.
  Priority:    Medium/Low, a good feature to prevent memory leaks but would
               have negative impact on memory usage and code size.

o Power Management (drivers/pm)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

o Signals (sched/signal, arch/)
  ^^^^^^^^^^^^^^^^^^^^^^^

  Title:       STANDARD SIGNALS
  Description: 'Standard' signals and signal actions are not supported.
               (e.g., SIGINT, SIGSEGV, etc).  Default is only SIG_IGN.

               Update:  SIGCHLD is supported if so configured.
  Status:      Open.  No further changes are planned.
  Priority:    Low, required by standards but not so critical for an
               embedded system.

  Title:       SIGEV_THREAD
  Description: Implementation of support for support for SIGEV_THREAD is available
               only in the FLAT build mode because it uses the OS work queues to
               perform the callback.  The alternative for the PROTECTED and KERNEL
               builds would be to create pthreads in the user space to perform the
               callbacks.  That is not a very attractive solution due to performance
               issues.  It would also require some additional logic to specify the
               TCB of the parent so that the pthread could be bound to the correct
               group.

               There is also some user-space logic in libc/aio/lio_listio.c.  That
               logic could use the user-space work queue for the callbacks.
  Status:      Low, there are alternative designs.  However, these features
               are required by the POSIX standard.
  Priority:    Low for now

  Title:       SIGNAL NUMBERING
  Description: In signal.h, the range of valid signals is listed as 0-31.  However,
               in many interfaces, 0 is not a valid signal number.  The valid
               signal number should be 1-32.  The signal set operations would need
               to map bits appropriately.
  Status:      Open
  Priority:    Low. Even if there are only 31 usable signals, that is still a lot.

o pthreads (sched/pthreads)
  ^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       PTHREAD_PRIO_PROTECT
  Description: Extend pthread_mutexattr_setprotocol().  It should support
               PTHREAD_PRIO_PROTECT (and so should its non-standard counterpart
               sem_setproto()).

               "When a thread owns one or more mutexes initialized with the
               PTHREAD_PRIO_PROTECT protocol, it shall execute at the higher of its
               priority  or  the  highest  of the priority ceilings of all the mutexes
               owned by this thread and initialized with this attribute, regardless of
               whether other threads are blocked on any of these mutexes or not.

               "While a thread is holding a mutex which has been initialized with
               the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol attributes,
               it shall not be subject to being moved to the tail of the scheduling queue
               at its priority in the event that its original priority is changed,
               such as by a call to sched_setparam(). Likewise, when a thread unlocks
               a mutex that has been initialized with the PTHREAD_PRIO_INHERIT or
               PTHREAD_PRIO_PROTECT protocol attributes, it shall not be subject to
               being moved to the tail of the scheduling queue at its priority in the
               event that its original priority is changed."

  Status:      Open.  No changes planned.
  Priority:    Low -- about zero, probably not that useful. Priority inheritance is
               already supported and is a much better solution.  And it turns out
               that priority protection is just about as complex as priority inheritance.
               Excerpted from my post in a Linked-In discussion:

               "I started to implement this HLS/"PCP" semaphore in an RTOS that I
                work with (http://www.nuttx.org) and I discovered after doing the
                analysis and basic code framework that a complete solution for the
                case of a counting semaphore is still quite complex -- essentially
                as complex as is priority inheritance.

               "For example, suppose that a thread takes 3 different HLS semaphores
                A, B, and C. Suppose that they are prioritized in that order with
                A the lowest and C the highest. Suppose the thread takes 5 counts
                from A, 3 counts from B, and 2 counts from C. What priority should
                it run at? It would have to run at the priority of the highest
                priority semaphore C. This means that the RTOS must maintain
                internal information of the priority of every semaphore held by
                the thread.

               "Now suppose it releases one count on semaphore B. How does the
                RTOS know that it still holds 2 counts on B? With some complex
                internal data structure. The RTOS would have to maintain internal
                information about how many counts from each semaphore are held
                by each thread.

               "How does the RTOS know that it should not decrement the priority
                from the priority of C? Again, only with internal complexity. It
                would have to know the priority of every semaphore held by
                every thread.

               "Providing the HLS capability on a simple pthread mutex would not
                be such quite such a complex job if you allow only one mutex per
                thread. However, the more general case seems almost as complex
                as priority inheritance. I decided that the implementation does
                not have value to me. I only wanted it for its reduced
                complexity; in all other ways I believe that it is the inferior
                solution. So I discarded a few hours of programming. Not a
                big loss from the experience I gained."

  Title:       INAPPROPRIATE USE OF sched_lock() BY pthreads
  Description: In implementation of standard pthread functions, the non-
               standard, NuttX function sched_lock() is used.  This is very
               strong since it disables pre-emption for all threads in all
               task groups.  I believe it is only really necessary in most
               cases to lock threads in the task group with a new non-
               standard interface, say pthread_lock().

               This is because the OS resources used by a thread such as
               mutexes, condition variable, barriers, etc. are only
               meaningful from within the task group.  So, in order to
               performance exclusive operations on these resources, it is
               only necessary to block other threads executing within the
               task group.

               This is an easy change:  pthread_lock() and pthread_unlock()
               would simply operate on a semaphore retained in the task
               group structure.  I am, however, hesitant to make this change:
               In the FLAT build model, there is nothing that prevents people
               from accessing the inter-thread controls from threads in
               differnt task groups.  Making this change, while correct,
               might introduce subtle bugs in code by people who are not
               using NuttX correctly.
  Status:      Open
  Priority:    Low.  This change would improve real-time performance of the
               OS but is not otherwise required.

o Message Queues (sched/mqueue)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

o Kernel/Protected Build
  ^^^^^^^^^^^^^^^^^^^^^^

  Title:       NSH PARTITIONING.
  Description: There are issues with several NSH commands in the NuttX kernel
               and protected build modes (where NuttX is built as a monolithic
               kernel and user code must trap into the protected kernel via
               syscalls). The current NSH implementation has several commands
               that call  directly into kernel internal functions for which
               there is no syscall available.  The commands cause link failures
               in the kernel/protected build mode and must currently be disabled.
               Here are known problems that must be fixed:

               COMMAND  KERNEL INTERFACE(s)
               -------- ----------------------------------------------
               mkrd     ramdisk_register()

  Status:      Open
  Priority:    Medium/High -- the kernel build configuration is not fully fielded
               yet.

  Title:       apps/system PARTITIONING
  Description: Several of the USB device helper applications in apps/system
               violate OS/application partitioning and will fail on a kernel
               or protected build.  Many of these have been fixed by adding
               the BOARDIOC_USBDEV_CONTROL boardctl() command.  But there are
               still issues.

               These functions still call directly into operating system
               functions:

                 - usbmsc_configure - Called from apps/system/usbmsc and
                   apps/system/composite
                 - usbmsc_bindlun - Called from apps/system/usbmsc
                 - usbmsc_exportluns - Called from apps/system/usbmsc.

  Status:      Open
  Priority:    Medium/High -- the kernel build configuration is not fully fielded
               yet.

  Title:       NxTERM PARTITIONING.
  Description: NxTerm is implemented (correctly) as a driver that resides
               in the nuttx/ directory.  However, the user interfaces must be
               moved into a NuttX library or into apps/.  Currently
               applications calls to the NxTerm user interfaces are
               undefined in the Kernel/Protected builds.
  Status:      Open
  Priority:    Medium

  Title:       C++ CONSTRUCTORS HAVE TOO MANY PRIVILEGES (PROTECTED MODE)
  Description: When a C++ ELF module is loaded, its C++ constructors are called
               via sched/task_starthook.c logic.  This logic runs in protected mode.
               The is a security hole because the user code runs with kernel-
               privileges when the constructor executes.

               Destructors likely have the opposite problem.  The probably try to
               execute some kernel logic in user mode?  Obviously this needs to
               be investigated further.
  Status:      Open
  Priority:    Low (unless you need build a secure C++ system).

  Title:       TOO MANY SYSCALLS
  Description: There are a few syscalls that operate very often in user space.
               Since syscalls are (relatively) time consuming this could be
               a performance issue.  Here is some numbers that I collected
               in an application that was doing mostly printf output:

                 sem_post - 18% of syscalls
                 sem_wait - 18% of syscalls
                 getpid   - 59% of syscalls
                 --------------------------
                            95% of syscalls

               Obviously system performance could be improved greatly by simply
               optimizing these functions so that they do not need to system calls
               so frequently.  This getpid() call is part of the re-entrant
               semaphore logic used with printf() and other C buffered I/O.
               Something like TLS might be used to retain the thread's ID
               locally.

               Linux, for example, has functions call up() and down().  up()
               increments the semaphore count but does not call into the kernel
               unless incrementing the count unblocks a task; similarly, down
               decrements the count and does not call into the kernel unless
               the count becomes negative the caller must be blocked.

               Update:
               "I am thinking that there should be a "magic" global, user-
                accessible variable that holds the PID of the currently
                executing thread; basically the PID of the task at the head
                of the ready-to-run list. This variable would have to be reset
                each time the head of the ready-to-run list changes.

               "Then getpid() could be implemented in user space with no system call
                by simply reading this variable.

               "This one would be easy: Just a change to include/nuttx/userspace.h,
                configs/*/kernel/up_userspace.c, libc/, sched/sched_addreadytorun.c, and
                sched/sched_removereadytorun.c. That would eliminate 59% of the syscalls."

               Update:
               This is probably also just a symptom of the OS test that does mostly
               console output.  The requests for the pid() are part of the
               implementation of the I/O's re-entrant semaphore implementation and
               would not be an issue in the more general case.

               Update:
               One solution might be to used CONFIG_TLS, add the PID to struct
               tls_info_s.  Then the PID could be obtained without a system call.
               TLS is not very useful in the FLAT build, however.  TLS works by
               putting per-thread data at the bottom of an aligned stack.  The
               current stack pointer is the ANDed with the alignment mask to
               obtain the per-thread data address.

               There are problems with this in the FLAT and PROTECTED builds:
               First the maximum size of the stack is limited by the number
               of bits in the mask.  This means that you need to have a very
               high alignment to support tasks with large stacks.  But
               secondly, the higher the alignment of the stacks stacks, the
               more memory is lost to fragmentation.

               In the KERNEL build, the the stack lies at a virtual address
               and it is possible to have highly aligned stacks with no such
               penalties.
  Status:      Open
  Priority:    Low-Medium.  Right now, I do not know if these syscalls are a
               real performance issue or not.  The above statistics were collected
               from a an atypical application (the OS test), and does an excessive
               amount of console output.  There is probably no issue with more typical
               embedded applications.

  Title:       SECURITY ISSUES
  Description: In the current designed, the kernel code calls into the user-space
               allocators to allocate user-space memory.  It is a security risk to
               call into user-space in kernel-mode because that could be exploited
               to gain control of the system.  That could be fixed by dropping to
               user mode before trapping into the memory allocators; the memory
               allocators would then need to trap in order to return (this is
               already done to return from signal handlers; that logic could be
               renamed more generally and just used for a generic return trap).

               Another place where the system calls into the user code in kernel
               mode is work_usrstart() to start the user work queue.  That is
               another security hole that should be plugged.
  Status:      Open
  Priority:    Low (unless security becomes an issue).

  Title:       MICRO-KERNEL
  Description: The initial kernel build cut many interfaces at a very high level.
               The resulting monolithic kernel is then rather large.  It would
               not be a prohibitively large task to reorganize the interfaces so
               that NuttX is built as a micro-kernel, i.e., with only the core
               OS services within the kernel and with other OS facilities, such
               as the file system, message queues, etc., residing in user-space
               and to interfacing with those core OS facilities through traps.
  Status:      Open
  Priority:    Low.  This is a good idea and certainly an architectural
               improvement.  However, there is no strong motivation now do
               do that partitioning work.

  Title:       USER MODE TASKS CAN MODIFY PRIVILEGED TASKS
  Description: Certain interfaces, such as sched_setparam(),
               sched_setscheduler(), etc. can be used by user mode tasks to
               modify the behavior of priviledged kernel threads.
               For a truly secure system.  Privileges need to be checked in
               every interface that permits one thread to modify the
               properties of another thread.

               NOTE:  It would be a simple matter to simply disable user
               threads from modifying privileged threads.  However, you
               might also want to be able to modify privileged threads from
               user tasks with certain permissions.  Permissions is a much
               more complex issue.

               task_delete(), for example, is not permitted to kill a kernel
               thread.  But should not a privileged user task be able to do
               so?
  Status:      Open
  Priority:    Low for most embedded systems but would be a critical need if
               NuttX were used in a secure system.

o C++ Support
  ^^^^^^^^^^^

  Title:       USE OF SIZE_T IN NEW OPERATOR
  Description: The argument of the 'new' operators should take a type of
               size_t (see libxx/libxx_new.cxx and libxx/libxx_newa.cxx).  But
               size_t has an unknown underlying.  In the nuttx sys/types.h
               header file, size_t is typed as uint32_t (which is determined by
               architecture-specific logic).  But the C++ compiler may believe
               that size_t is of a different type resulting in compilation errors
               in the operator.  Using the underlying integer type Instead of
               size_t seems to resolve the compilation issues.
  Status:      Kind of open.  There is a workaround.  Setting CONFIG_CXX_NEWLONG=y
               will define the operators with argument of type unsigned long;
               Setting CONFIG_CXX_NEWLONG=n will define the operators with argument
               of type unsigned int.  But this is pretty ugly!  A better solution
               would be to get a hold of the compilers definition of size_t.
  Priority:    Low.

  Title:       STATIC CONSTRUCTORS AND MULTITASKING
  Description: The logic that calls static constructors operates on the main
               thread of the initial user application task.  Any static
               constructors that cache task/thread specific information such
               as C streams or file descriptors will not work in other tasks.
               See also UCLIBC++ AND STATIC CONSTRUCTORS below.
  Status:      Open
  Priority:    Low and probably will not changed.  In these case, there will
               need to be an application specific solution.

  Title:       UCLIBC++ AND STATIC CONSTRUCTORS
               uClibc++ was designed to work in a Unix environment with
               processes and with separately linked executables. Each process
               has its own, separate uClibc++ state. uClibc++ would be
               instantiated like this in Linux:

               1) When the program is built, a tiny start-up function is
                  included at the beginning of the program. Each program has
                  its own, separate list of C++ constructors.

               2) When the program is loaded into memory, space is set aside
                  for uClibc's static objects and then this special start-up
                  routine is called. It initializes the C library, calls all
                  of the constructors, and calls atexit() so that the destructors
                  will be called when the process exits.

               In this way, you get a per-process uClibc++ state since there
               is per-process storage of uClibc++ global state and per-process
               initialization of uClibc++ state.

               Compare this to how NuttX (and most embedded RTOSs) would work:

               1) The entire FLASH image is built as one big blob. All of the
                  constructors are lumped together and all called together at
                  one time.

                  This, of course, does not have to be so. We could segregate
                  constructors by some criteria and we could use a task start
                  up routine to call constructors separately. We could even
                  use ELF executables that are separately linked and already
                  have their constructors separately called when the ELF
                  executable starts.

                  But this would not do you very much good in the case of
                  uClibc++ because:

               2) NuttX does not support processes, i.e., separate address
                  environments for each task. As a result, the scope of global
                  data is all tasks. Any change to the global state made by
                  one task can effect another task. There can only one
                  uClibc++ state and it will be shared by all tasks. uClibc++
                  apparently relies on global instances (at least for cin and
                  cout) there is no way to to have any unique state for any
                  "task group".

                  [NuttX does not support processes because in order to have
                  true processes, your hardware must support a memory management
                  unit (MMU) and I am not aware of any mainstream MCU that has
                  an MMU (or, at least an MMU that is capable enough to support
                  processes).]

                  NuttX does not have processes, but it does have "task groups".
                  See http://www.nuttx.org/doku.php?id=wiki:nxinternal:tasksnthreads.
                  A task group is the task plus all of the pthreads created by
                  the task via pthread_create().  Resources like FILE streams
                  are shared within a task group. Task groups are like a poor
                  man's process.

                  This means that if the uClibc++ static classes are initialized
                  by one member of a task group, then cin/cout should work
                  correctly with all threads that are members of task group. The
                  destructors would be called when the final member of the task
                  group exists (if registered via atexit()).

                  So if you use only pthreads, uClibc++ should work very much like
                  it does in Linux. If your NuttX usage model is like one process
                  with many threads then you have Linux compatibility.

               If you wanted to have uClibc++ work across task groups, then
               uClibc++ and NuttX would need some extensions. I am thinking
               along the lines of the following:

               1) There is a per-task group storage are within the RTOS (see
                  include/nuttx/sched.h). If we add some new, non-standard APIs
                  then uClibc++ could get access to per-task group storage (in
                  the spirit of pthread_getspecific() which gives you access to
                  per-thread storage).

               2) Then move all of uClibc++'s global state into per-task group
                  storage and add a uClibc++ initialization function that would:
                  a) allocate per-task group storage, b) call all of the static
                  constructors, and c) register with atexit() to perform clean-
                  up when the task group exits.

               That would be a fair amount of effort. I don't really know what
               the scope of such an effort would be. I suspect that it is not
               large but probably complex.

               NOTES:

               1) See STATIC CONSTRUCTORS AND MULTITASKING

               2) To my knowledge, only some uClibc++ ofstream logic is
                  sensitive to this.  All other statically initialized classes
                  seem to work OK across different task groups.
  Status:      Open
  Priority:    Low.  I have no plan to change this logic now unless there is
               some strong demand to do so.

o Binary loaders (binfmt/)
  ^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       NXFLAT TESTS
  Description: Not all of the NXFLAT test under apps/examples/nxflat are working.
               Most simply do not compile yet.  tests/mutex runs okay but
               outputs garbage on completion.

               Update: 13-27-1, tests/mutex crashed with a memory corruption
               problem the last time that I ran it.
  Status:      Open
  Priority:    High

  Title:       ARM UP_GETPICBASE()
  Description: The ARM up_getpicbase() does not seem to work.  This means
               the some features like wdog's might not work in NXFLAT modules.
  Status:      Open
  Priority:    Medium-High

  Title:       NXFLAT READ-ONLY DATA IN RAM
  Description: At present, all .rodata must be put into RAM.  There is a
               tentative design change that might allow .rodata to be placed
               in FLASH (see Documentation/NuttXNxFlat.html).
  Status:      Open
  Priority:    Medium

  Title:       GOT-RELATIVE FUNCTION POINTERS
  Description: If the function pointer to a statically defined function is
               taken, then GCC generates a relocation that cannot be handled
               by NXFLAT.  There is a solution described in Documentation/NuttXNxFlat.html,
               by that would require a compiler change (which we want to avoid).
               The simple workaround is to make such functions global in scope.
  Status:      Open
  Priority:    Low (probably will not fix)

  Title:       USE A HASH INSTEAD OF A STRING IN SYMBOL TABLES
  Description: In the NXFLAT symbol tables... Using a 32-bit hash value instead
               of a string to identify a symbol should result in a smaller footprint.
  Status:      Open
  Priority:    Low

  Title:       WINDOWS-BASED TOOLCHAIN BUILD
  Description: Windows build issue.  Some of the configurations that use NXFLAT have
               the linker script specified like this:

               NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.ld -no-check-sections

               That will not work for windows-based tools because they require Windows
               style paths.  The solution is to do something like this:

               if ($(WINTOOL)y)
                 NXFLATLDSCRIPT=${cygpath -w $(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.ld}
               else
                 NXFLATLDSCRIPT=$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.ld
               endif

               Then use

               NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T"$(NXFLATLDSCRIPT)" -no-check-sections

  Status:      Open
  Priority:    There are too many references like the above.  They will have
               to get fixed as needed for Windows native tool builds.

  Title:       TOOLCHAIN COMPATIBILITY PROBLEM
  Description: The older 4.3.3 compiler generates GOTOFF relocations to the constant
               strings, like:

               .L3:
                  .word   .LC0(GOTOFF)
                  .word   .LC1(GOTOFF)
                  .word   .LC2(GOTOFF)
                  .word   .LC3(GOTOFF)
                  .word   .LC4(GOTOFF)

               Where .LC0, LC1, LC2, LC3, and .LC4 are the labels corresponding to strings in
               the .rodata.str1.1 section.  One consequence of this is that .rodata must reside
               in D-Space since it will addressed relative to the GOT (see the section entitled
               "Read-Only Data in RAM" at
               http://nuttx.org/Documentation/NuttXNxFlat.html#limitations).

               The newer 4.6.3 compiler generated PC relative relocations to the strings:

               .L2:
                  .word   .LC0-(.LPIC0+4)
                  .word   .LC1-(.LPIC1+4)
                  .word   .LC2-(.LPIC2+4)
                  .word   .LC3-(.LPIC4+4)
                  .word   .LC4-(.LPIC5+4)

               This is good and bad.  This is good because it means that .rodata.str1.1 can now
               reside in FLASH with .text and can be accessed using PC-relative addressing.
               That can be accomplished by simply moving the .rodata from the .data section to
               the .text section in the linker script.  (The NXFLAT linker script is located at
               nuttx/binfmt/libnxflat/gnu-nxflat.ld).

               This is bad because a lot of stuff may get broken an a lot of test will need to
               be done.  One question that I have is does this apply to all kinds of .rodata?
               Or just to .rodata.str1.1?

  Status:      Open.  Many of the required changes are in place but, unfortunately, not enough
               go be fully functional.  I think all of the I-Space-to-I-Space fixes are in place.
               However, the generated code also includes PC-relative references to .bss which
               just cannot be done.
  Priority:    Medium.  The workaround for now is to use the older, 4.3.3 OABI compiler.

o Network (net/, drivers/net)