TODO

NuttX TODO List (Last updated September 29, 2014)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This file summarizes known NuttX bugs, limitations, inconsistencies with
standards, things that could be improved, and ideas for enhancements.  See
also individual README.txt files in the configs/ sub-directories for each
board port.

nuttx/

  (9)  Task/Scheduler (sched/)
  (2)  Memory Managment (mm/)
  (3)  Signals (sched/, arch/)
  (2)  pthreads (sched/)
  (8)  Kernel/Protected Builds
  (4)  C++ Support
  (6)  Binary loaders (binfmt/)
 (13)  Network (net/, drivers/net)
  (4)  USB (drivers/usbdev, drivers/usbhost)
 (10)  Libraries (libc/, )
 (11)  File system/Generic drivers (fs/, drivers/)
  (6)  Graphics subystem (graphics/)
  (1)  Pascal add-on (pcode/)
  (1)  Documentation (Documentation/)
  (5)  Build system / Toolchains
  (5)  Linux/Cywgin simulation (arch/sim)
  (4)  ARM (arch/arm/)
  (1)  ARM/C5471 (arch/arm/src/c5471/)
  (3)  ARM/DM320 (arch/arm/src/dm320/)
  (2)  ARM/i.MX (arch/arm/src/imx/)
  (3)  ARM/LPC17xx (arch/arm/src/lpc17xx/)
  (7)  ARM/LPC214x (arch/arm/src/lpc214x/)
  (2)  ARM/LPC313x (arch/arm/src/lpc313x/)
  (0)  ARM/LPC43x (arch/arm/src/lpc43xx/)
  (3)  ARM/STR71x (arch/arm/src/str71x/)
  (3)  ARM/LM3S6918 (arch/arm/src/lm/)
  (x)  ARM/SAMA5D3 ((arch/arm/src/sama5/)
  (5)  ARM/STM32 (arch/arm/src/stm32/)
  (3)  AVR (arch/avr)
  (0)  Intel x86 (arch/x86)
  (3)  MIPS/PIC32 (arch/mips)
  (1)  Hitachi/Renesas SH-1 (arch/sh/src/sh1)
  (4)  Renesas M16C/26 (arch/sh/src/m16c)
 (11)  z80/z8/ez80/z180 (arch/z80/)
  (9)  z16 (arch/z16/)
  (1)  mc68hc1x (arch/hc)

apps/

  (4)  Network Utilities (apps/netutils/)
  (3)  NuttShell (NSH) (apps/nshlib)
  (1)  System libraries apps/system (apps/system)
  (5)  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.

  Title:       pause() NON-COMPLIANCE
  Description: In the POSIX description of this function is the pause() function
               will 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
               NutX 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:       INCOMPATIBILITES 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() AND on_exit()
  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?

               The fix for all of these issues it to have the callbacks
               run on the caller's thread (as with signal handlers).
  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 appliction:  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 childs 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

o Memory Managment (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).

  Status:      Open.  No changes are planned.
  Priority:    Medium/Low, a good feature to prevent memory leaks but would
               have negative impact on memory usage and code size.

  Title:       KERNEL MODE PAGE ALLOCATOR
  Description: The KERNEL mode build for platforms with an MMU really needs
               a page-oriented allocator and support for sbrk() and brk()
  Status:      Open
  Priority:    Low

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

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

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

  Title:       SIGEV_THREAD
  Description: sig_notify() logic does not support SIGEV_THREAD; structure
               struct sigevent does not provide required members sigev_notify_function
               or sigev_notify_attributes.
  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/)
  ^^^^^^^^^^^^^^^^^

  Title:       CANCELLATION POINTS
  Description: pthread_cancel():  Should implement cancellation points and
               pthread_testcancel()
  Status:      Open.  No changes are planned.
  Priority:    Low, probably not that useful

  Title:       PTHREAD_PRIO_PROTECT
  Description: Extended pthread_mutexattr_setprotocol() suport PTHREAD_PRIO_PROTECT:
               "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.
               Exerpted 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 phread 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."

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)
               -------- ----------------------------------------------
               losetup  losetup(), loteardown()
               mkfatfs  mkfatfs
               mkrd     ramdisk_register()
               dd       bchlib_setup(), bchlib_read(), bchlib_write(),
                        bchlib_teardown()
               ps       sched_foreach()
               ifup     netdev_foreach()
               ifdown   netdev_foreach()
               ifconfig netdev_foreach(), g_netstats
               ping     icmp_ping()

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

  Title:       NSH free COMMAND LIMITATION
  Description: The NSH 'free' command only shows memory usage in the user
               heap only, not usage in the kernel heap.  I am thinking that
               kernel heap memory usage should be available in /proc/memory.
  Status:      Open
  Priority:    Medium/High

  Title:       TELNETD PARTITIONING.
  Description: Telnetd is implemented as a driver that resides in the apps/
               directory.  In the kernel/protected build modes, the driver
               logic must be moved into the kernel part of the build (nuttx/,
               although the application level interfaces must stay in apps/).
  Status:      Open
  Priority:    Medium

  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.
  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 outout:

                 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.  getpid() is (I believe) part of the re-entrant
               semaphore logic.  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.
  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.

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
  Description: Need to call static constructors
               Update:  Static constructors are implemented for the STM32 F4 and
               this will provide the model for all solutions.  Basically, if
               CONFIG_HAVE_CXXINITIALIZE=y is defined in the configuration, then
               board-specific code must provide the interface up_cxxinitialize().
               up_cxxinitialize() is called from aplication logic to initialize
               all static class instances.  This TODO item probably has to stay
               open because this solution is only available on STM32 F4.
  Status:      Open
  Priority:    Low, depends on toolchain.  Call to gcc's built-in static
               constructor logic will probably have to be performed by
               user logic in the application.

  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 withing the RTOS (see
                  include/nuttx/sched.h). If we add some new, nonstandard 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:       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
  Descripton:  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 correponding 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.3compiler 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)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       MULTIPLE NETWORK INTERFACE SUPPORT
  Description: uIP polling issues / Multiple network interface support:

               (1) Current logic will not support multiple Ethernet drivers.
                  Each driver should poll on TCP connections connect on the
                  network supported by the driver; UDP polling should respond
                  with TX data only if the UDP packet is intended for the
                  the network supported by the driver.

               (2) If there were multiple drivers, polling would occur at
                  double the rate.  Fix by using bound IP address in TCP
                  connection (lipaddr) and verifying that it is in the subnet
                  served by the driver.

               Another issue:  When sending packets to another subnet, the
               current logic falls back and uses ETH0 if it cannot find the
               device for the subnet.  That lookup would need to be smarter...
               perhaps it needs a routing table.

  Status:      Open.  Nothing will probably be done until I have a platform
               with two network interfaces that I need to support.
  Priority:    Medium, The feature is not important, but it is important
               for NuttX to resolve the architectural issues.

  Title:       SENDTO() AND MULTIPLE NETWORK INTERFACE SUPPORT
  Description: sendto() and multiple network interface support:
               When polled, would have to assure that the destination IP
               is on the subnet served by the polling driver.
  Status:      Open.  This is really part of the above issue.
  Priority:    Medium, The feature is not important, but it is important
               for NuttX to resolve the architectural issues.

  Title:       IPv6
  Description: IPv6 support is incomplete.  Adam Dunkels has recently announced
               IPv6 support for uIP (currently only as part of Contiki).  Those
               changes need to be ported to NuttX.
  Status:      Open.  No work will probably be done until there is a specific
               requirement for IPv6.
  Priority:    Medium

  Title:       LISTENING FOR UDP BROADCASTS
  Description: Incoming UDP broadcast should only be accepted if listening on
               INADDR_ANY(?)
  Status:      Open
  Priority:    Low

  Title:       STANDARDIZE ETHERNET DRIVER STATISTICS
  Description: Need to standardize collection of statistics from network
               drivers.  apps/nshlib ifconfig command should present
               statistics.
  Status:      Open
  Priority:    Low.  This is not a bug but an enhancement idea.

  Title:       CONCURRENT 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.
  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.

  Title:       UDP READ-AHEAD?
  Description: TCP supports read-ahead buffering to handle the receipt of
               TCP/IP packets when there is no read() in place.  Should such
               capability be useful for UDP?  PRO: Would reduce packet loss
               and enable support for poll()/select().  CON: UDP is inherently
               lossy so why waste memory footprint?
  Status:      Open
  Priority:    Medium

  Title:       NO POLL/SELECT ON UDP SOCKETS
  Description: poll()/select() is not implemented for UDP sockets because they do
               do not support read-ahead buffering.  Therefore, there is never
               a case where you can read from a UDP socket without blocking.
  Status:      Open, depends on UDP read-ahead support
  Priority:    Medium

  Title:       POLL/SELECT ON TCP SOCKETS NEEDS READ-AHEAD
  Description: poll()/select() only works for availability of buffered TCP
               read data (when read-ahead is enabled).  The way writing is
               handled in uIP, all sockets must wait when send and cannot
               be notified when they can send without waiting.
  Status:      Open, probably will not be fixed.
  Priority:    Medium... this does effect porting of applications that expect
               different behavior from poll()/select()

  Title:       SOCKETS DO NOT ALWAYS SUPPORT O_NONBLOCK
  Description: sockets do not support all modes for O_NONBLOCK. Sockets
               support only (1) TCP/IP non-blocking read operations when read-ahead
               buffering is enabled, and (2) TCP/IP accept() operations when TCP/IP
               connection backlog is enabled.
  Status:      Open
  Priority:    Low.

  Title:       UNFINISHED CRYSTALLAN CS89X0 DRIVER
  Description: I started coding a CrystalLan CS89x0 driver (drivers/net/cs89x0.c),
               but never finished it.
  Status:      Open
  Priority:    Low unless you need it.

  Title:       INTERFACES TO LEAVE/JOIN IGMP MULTICAST GROUP
  Description: The interfaces used to leave/join IGMP multicast groups is non-standard.
               RFC3678 (IGMPv3) suggests ioctl() commands to do this (SIOCSIPMSFILTER) but
               also status that those APIs are historic.  NuttX implements these ioctl
               commands, but is non-standard because:  (1) It does not support IGMPv3, and
               (2) it looks up drivers by their device name (eg., "eth0") vs IP address.

               Linux uses setsockopt() to control multicast group membership using the
               IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP options.  It also looks up drivers
               using IP addresses (It would require additional logic in NuttX to look up
               drivers by IP address).  See http://tldp.org/HOWTO/Multicast-HOWTO-6.html
  Status:      Open
  Priority:    Medium.  All standards compatibility is important to NuttX.  However, most
               the mechanism for leaving and joining groups is hidden behind a wrapper
               function so that little of this incompatibilities need be exposed.

  Title:       CLOSED CONNECTIONS IN THE BACKLOG
               If a connection is backlogged but accept() is not called quickly, then
               that connection may time out.  How should this be handled?  Should the
               connection be removed from the backlog if it is times out or is closed?
               Or should it remain in the backlog with a status indication so that accept()
               can fail when it encounteres the invalid connection?
  Status:      Open
  Priority:    Medium.  Important on slow applications that will not accept
               connections promptly.

o USB (drivers/usbdev, drivers/usbhost)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       USB STORAGE DRIVER DELAYS
  Description: There is a workaround for a bug in drivers/usbdev/usbdev_storage.c.
               that involves delays.  This needs to be redesigned to eliminate these
               delays.  See logic conditioned on CONFIG_USBMSC_RACEWAR.

               If queuing of stall requests is supported by DCD then this workaround
               is not required.  In this case, (1) the stall is not sent until all
               write requests preceding the stall request are sent, (2) the stall is
               sent, and then after the stall is cleared, (3) all write requests
               queued after the stall are sent.

               See, for example, the queuing of pending stall requests in the SAM3/4
               UDP driver at arch/arm/src/sam34/sam_udp.c.  There the logic is do this
               is implemented with a normal request queue, a pending request queue, a
               stall flag and a stall pending flag:

               1) If the normal request queue is not empty when the STALL request is
                  received, the stall pending flag is set.
               2) If addition write requests are received while the stall pending flag
                  is set (or while waiting for the stall to be sent), those write requests
                  go into the pending queue.
               3) When the normal request queue empties successful and all of the write
                  transfers complete, the STALL is sent.  The stall pending flag is
                  cleared and the stall flag is set.  Now the endpoint is really stalled.
               4) After the STALL is cleared (via the Clear Feature SETUP), the pending
                  request queue is copied to the normal request queue, the stall flag is
                  cleared, and normal write request processing resumes.

  Status:      Open
  Priority:    Medium

  Title:       RTL8187 DRIVER IS UNFINISHED
  Description: misc/drivers/usbhost_rtl8187.c is a work in progress.  There is no RTL8187
               driver available yet.  That is a work in progress it was abandoned because
               it depends on having an 802.11g stack.
  Status:      Open
  Priority:    Low (Unless you need RTL8187 support).

  Title:       EP0 OUT CLASS DATA
  Description: There is no mechanism in place to handle EP0 OUT data transfers.
               There are two aspects to this problem, neither are easy to fix
               (only because of the number of drivers that would be impacted):

               1. The class drivers only send EP0 write requests and these are
                  only queued on EP0 IN by this drivers.  There is never a read
                  request queued on EP0 OUT.
               2. But EP0 OUT data could be buffered in a buffer in the driver
                  data structure.  However, there is no method currently
                  defined in the USB device interface to obtain the EP0 data.

               Updates:  (1) The USB device-to-class interface as been extended so
               that EP0 OUT data can accompany the SETUP request sent to the
               class drivers. (2) The logic in the STM32 F4 OTG FS device driver
               has been extended to provide this data.  Updates are still needed
               to other drivers.

               Here is an overview of the required changes:
               New two buffers in driver structure:

               1. The existing EP0 setup request buffer (ctrlreq, 8 bytes)
               2. A new EP0 data buffer to driver state structure (ep0data,
                  max packetsize)

               Add a new state:

               3. Waiting for EP0 setup OUT data (EP0STATE_SETUP_OUT)

               General logic flow:

               1. When an EP0 SETUP packet is received:
                  - Read the request into EP0 setup request buffer (ctrlreq,
                    8 bytes)
                  - If this is an OUT request with data length, set the EP0
                    state to EP0STATE_SETUP_OUT and wait to receive data on
                    EP0.
                  - Otherwise, the SETUP request may be processed now (or,
                    in the case of the F4 driver, at the conclusion of the
                    SETUP phase).
               2. When EP0 the EP0 OUT DATA packet is received:
                  - Verify state is EP0STATE_SETUP_OUT
                  - Read the request into the EP0 data buffer (ep0data, max
                    packet size)
                  - Now process the previously buffered SETUP request along
                    with the OUT data.
               3. When the setup packet is dispatched to the class driver,
                  the OUT data must be passed as the final parameter in the
                  call.

               Update 2013-9-2:  The new USB device-side driver for the SAMA5D3
               correctly supports OUT SETUP data following the same design as
               per above.

               Update 2013-11-7: David Sidrane has fixed with issue with the
               STM32 F1 USB device driver.  Still a few more to go before this
               can be closed out.

  Status:      Open
  Priority:    High for class drivers that need EP0 data.  For example, the
               CDC/ACM serial driver might need the line coding data (that
               data is not used currently, but it might be).

  Title:       USB HUB SUPPORT
  Description: Add support for USB hubs
  Status:      Open
  Priority:    Low/Unknown.  This is a feature enhancement.

o Libraries (libc/)
  ^^^^^^^^^^^^^^^^^

  Title:       SIGNED time_t
  Description: The NuttX time_t is type uint32_t. I think this is consistent
               with all standards and with normal usage of time_t.  However,
               according to Wikipedia, time_t is usually implemented as a
               signed 32-bit value.
  Status:      Open
  Priority:    Very low unless there is some compelling issue that I do not
               know about.

  Title:       ENVIRON
  Description: The definition of environ in stdlib.h is bogus and will not
               work as it should.  This is because the underlying
               representation of the environment is not an arry of pointers.
  Status:      Open
  Priority:    Medium

  Title:       TERMIOS
  Description: Need some minimal termios support... at a minimum, enough to
               switch between raw and "normal" modes to support behavior like
               that needed for readline().
               UPDATE:  There is growing functionality in libc/termios/ and in the
               ioctl methods of several MCU serial drivers (stm32, lpc43, lpc17,
               pic32).  However, as phrased, this bug cannot yet be closed since
               this "growing functionality" does not address all termios.h
               functionality and not all serial drivers support termios.
  Status:      Open
  Priority:    Low

  Title:       DAYS OF THE WEEK
  Description: strftime() and other timing functions do not handle days of the week.
  Status:      Open
  Priority:    Low