nuttx/TODO

NuttX TODO List (Last updated May 3, 2015)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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/

 (11)  Task/Scheduler (sched/)
  (1)  Memory Management (mm/)
  (3)  Signals (sched/signal, arch/)
  (2)  pthreads (sched/pthread)
  (0)  Message Queues (sched/mqueue)
  (4)  C++ Support
  (6)  Binary loaders (binfmt/)
 (12)  Network (net/, drivers/net)
  (3)  USB (drivers/usbdev, drivers/usbhost)
 (12)  Libraries (libc/, libm/)
 (11)  File system/Generic drivers (fs/, drivers/)
  (8)  Graphics subsystem (graphics/)
  (1)  Pascal add-on (pcode/)
  (2)  Build system / Toolchains
  (3)  Linux/Cywgin simulation (arch/sim)
  (5)  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/)
  (2)  ARM/STR71x (arch/arm/src/str71x/)
  (2)  ARM/LM3S6918 (arch/arm/src/tiva/)
  (x)  ARM/SAMA5D3/4 ((arch/arm/src/sama5/)
  (x)  ARM/SAMV7 ((arch/arm/src/samv7/)
  (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)
  (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.

  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 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:       REMOVE TASK_DELETE
  Description: Need to remove or fix task delete.  This interface is non-
               standard and not safe.  Arbitrary deleting tasks can cause
               serious problems such as memory leaks.  Better to remove it
               than to retain it as a latent bug.

               Currently used within the OS and also part of the
               implementation of pthread_cancel() and task_restart() (which
               should also go for the same reasons).  It is used in
               NxWM::CNxConsole to terminate console tasks and also in
               apps/netutils/thttpd to kill CGI tasks that timeout.
  Status:      Open
  Priority:    Low and not easily removable.

  Title:       RELEASE SEMAPHORES HELD BY CANCELED THREADS:
  Description: Commit: fecb9040d0e54baf14b729e556a832febfe8229e: "In
                case a thread is doing a blocking operation (e.g. read())
                on a serial device, while it is being terminated by
                pthread_cancel(), then uart_close() gets called, but
                the semaphore (dev->recv.sem in the above example) is
                still blocked.

               "This means that once the serial device is opened next
                time, data will arrive on the serial port (and driver
                interrupts handled as normal), but the received characters
                never arrive in the reader thread.

                This patch addresses the problem by re-initializing the
                semaphores on the last uart_close() on the device."

               Yahoo! Groups message 7726: "I think that the system
                should be required to handle pthread_cancel safely in
                all cases.  In the NuttX model, a task is like a Unix
                process and a pthread is like a Unix thread.  Cancelling
                threads should always be safe (or at least as unsafe) as
                under Unix because the model is complete for pthreads...

               "So, in my opinion, this is a generic system issue, not
                specific to the serial driver.  I could also implement
                logic to release all semaphores held by a thread when
                it exits -- but only if priority inheritance is enabled;
                because only in that case does the code have any memory
                of which threads actually hold the semaphore.

               "The patch I just incorporated is also insufficient.  It
                works only if the serial driver is shut down when the
                thread is cancelled.  But what if there are other open
                references to the driver?  Then the driver will not be
                shut down, the semaphores will not be re-initialized, and
                the semaphore counts will still be off by one.

               "I think that the system needs to automatically release any
                semaphores held by a thread being killed asynchronously?
                It seems necessary to me."

               UPDATE; The logic enabled when priority inheritance is
               enabled for this purpose is insufficient.  It provides
               hooks so that given a semaphore it can traverse all
               holders.  What is needed would be logic so that given
               a task, you can traverse all semaphores held by the task,
               releasing each semaphore cound held by the exiting task.
               Nothing like this exists now so that solution is not
               imminent.

               UPDATE: The basic fix to release the semaphore count if
               a thread is killed via pthread_cancel() or task_delete()
               has been implemented (2014-12-13).  See the new file:
               sched/semaphore/sem_recover.c  However, the general
               issue of freeing semaphores when a thread exists still
               exists.
  Status:      Open
  Priority:    Medium-ish

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.

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

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

               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: 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/pthreads)
  ^^^^^^^^^^^^^^^^^

  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() support 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 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."

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)
               -------- ----------------------------------------------
               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 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.  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 application 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 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
  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:       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.  Currently they are useless because they are not
               accessible.  The solution is to standardize the structure
               that holds the drivers statistics.  Then apps/nshlib
               ifconfig command could present the driver statistics.

               Currently these drivers support non-standard statistics:

                 arch/arm/src/kinetis/kinetis_enet.c
                 arch/arm/src/lpc17xx/lpc17_ethernet.c
                 arch/arm/src/tiva/lm3s_ethernet.c
                 arch/mips/src/pic32mx/pic32mx-ethernet.c
                 arch/z80/src/ez80/ez80_emac.c

               The other Ethernet drivers support no 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:       POLL/SELECT ON TCP/UDP SOCKETS NEEDS READ-AHEAD
  Description: poll()/select() only works for availability of buffered TCP/UDP
               read data (when read-ahead is enabled).  The way writing is
               handled in the network layer, 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 nonblocking operations only (1) for TCP/IP non-
               blocking read operations when read-ahead buffering is
               enabled, (2) TCP/IP accept() operations when TCP/IP
               connection backlog is enabled, (2) UDP/IP read() operations
               when UDP read-ahead is enabled, and (3) non-blocking
               operations on Unix domain sockets.
  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.

  Title:       INTERRUPT LEVEL PROCESSING IN ETHERNET DRIVERS
  Description: Too many Ethernet drivers do interrupt-level processing with
               the network stack.  The network stack supports either interrupt
               level processing or normal task level processing (depending on
               CONFIG_NET_NOINTS).  This is really a very bad use of CPU
               resources;  All of the network stack processing should be
               modified to use a work queue (and, all use of CONFIG_NET_NOINTS=n
               should be eliminated).  This applies to almost all Ethernet
               drivers:

               ARCHITECTURE   CONFIG_NET_NOINTS?      ADDRESS FILTER SUPPORT?
               C5471          NO                      NO
               STM32          YES                     YES
               TIVA           ----------------------- ------
                 LM3S         NO                      NO
                 TM4C         YES                     YES
               eZ80           NO                      NO
               LPC17xx        YES (could be issues)   YES (not tested)
               DMxxx NIC      NO                      NO
               PIC32          NO                      NO
               RGMP           ???                     ???
               SAM3/4         YES                     YES
               SAMA5D         ----------------------- ------
                 EMACA        NO                      YES (not tested)
                 EMACB        YES                     YES
                 GMAC         NO                      YES (not tested)
               SAMV7          YES                     YES
               SIM            N/A  (No interrupts)    NO

               The general outline of how this might be done is included in
               drivers/net/skeleton.c
  Status:      Open
  Priority:    Pretty high if you want a well behaved system.

  Title:       UDP MULTICAST RECEPTION
  Description: The logic in udp_input() expects either a single receive socket or
               none at all.  However, multiple sockets should be capable of
               receiving a UDP datagram (multicast reception).  This could be
               handled easily by something like:

                for (conn = NULL; conn = udp_active (pbuf, conn); )

               If the callback logic that receives a packet responds with an
               outgoing packet, then it will over-write the received buffer,
               however.  recvfrom() will not do that, however.  We would have
               to make that the rule: Recipients of a UDP packet must treat
               the packet as read-only.
  Status:      Open
  Priority:    Low, unless your logic depends on that behavior.

  Title:       NETWORK WON'T STAY DOWN
  Description: If you enable the NSH network monitor (CONFIG_NSH_NETINIT_MONITOR)
               then the NSH 'ifdown' command is broken.  Doing 'nsh> ifconfig eth0'
               will, indeed, bring the network down.  However, the network monitor
               notices the change in the link status and will bring the network
               back up.  There needs to be some kind of interlock between
               cmd_ifdown() and the network monitor thread to prevent this.
  Status:      Open
  Priority:    Low, this is just a nuisance in most cases.

  Title:       FIFO CLEAN-UP AFTER CLOSING UNIX DOMAIN DATAGRAM SOCKET
  Description: FIFOs are used as the IPC underlying all local Unix domain
               sockets.  In NuttX, FIFOs are implemented as device drivers
               (not as a special FIFO files).  The FIFO device driver is
               instantiated when the Unix domain socket communications begin
               and will automatically be released when (1) the driver is
               unlinked and (2) all open references to the driver have been
               closed.  But there is no mechanism in place now to unlink the
               FIFO when the Unix domain datagram socket is no longer used.
               The primary issue is timing.. the FIFO should persist until
               it is no longer needed.  Perhaps there should be a delayed
               call to unlink() (using a watchdog or the work queue).  If
               the driver is re-opened, the delayed unlink could be
               cancelled?  Needs more thought.
               NOTE: This is not an issue for Unix domain streams sockets:
               The end-of-life of the FIFO is well determined when sockets
               are disconnected and support for that case is fully implemented.
  Status:      Open
  Priority:    Low for now because I don't have a situation where this is a
               problem for me.  If you use the same Unix domain paths, then
               it is not a issue; in fact it is more efficient if the FIFO
               devices persist.  But this would be a serious problem if,
               for example, you create new Unix domain paths dynamically.
               In that case you would effectively have a memory leak and the
               number of FIFO instances grow.

  Title:       TCP IPv4-MAPPED IPv6 ADDRESSES
  Description: The UDP implementation in net/udp contains support for Hybrid
               dual-stack IPv6/IPv4 implementations that utilize a special
               class of addresses, the IPv4-mapped IPv6 addresses.  You can
               see that UDP implementation in:

                 udp_callback.c:
                   ip6_map_ipv4addr(ipv4addr,
                 udp_send.c:
                   ip6_is_ipv4addr((FAR struct in6_addr*)conn->u.ipv6.raddr)))
                   ip6_is_ipv4addr((FAR struct in6_addr*)conn->u.ipv6.raddr))
                   in_addr_t raddr = ip6_get_ipv4addr((FAR struct in6_addr*)conn->u.ipv6.raddr);

               There is no corresponding support for TCP sockets.
  Status:      Open
  Priority:    Low.  I don't know of any issues now, but I am sure that
               someone will encounter this in the future.

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).

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 array 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

  Title:       RESETTING GETOPT()
  Description: There is an issue with the way that getopt() handles errors that
               return '?'.

               1. Does getopt() reset its global variables after returning '?' so
                  that it can be re-used?  That would be required to support where
                  the caller terminates parsing before reaching the last parameter.
               2. Or is the client expected to continue parsing after getopt()
                  returns '?'  and parse until the final parameter?

               The current getopt() implementation only supports #2.
  Status:      Open
  Priority:    Low

  Title:       CONCURRENT STREAM READ/WRITE
  Description: NuttX only supports a single file pointer so reads and writes
               must be from the same position.  This prohibits implementation
               of behavior like that required for fopen() with the "a+" mode.
               According to the fopen man page:

               "a+ Open for reading and appending (writing at end of file).
                The file is created if it does not exist. The initial file
                position for reading is at the beginning of the file, but
                output is always appended to the end of the file."

               At present, the single NuttX file pointer is positioned to the
               end of the file for both reading and writing.
  Status:      Open
  Priority:    Medium.  This kind of operation is probably not very common in
               deeply embedded systems but is required by standards.

  Title:       DIVIDE BY ZERO
  Description: This is bug 3468949 on the SourceForge website (submitted by
               Philipp Klaus Krause):
               "lib_strtod.c does contain divisions by zero in lines 70 and 96.
                AFAIK, unlike for Java, division by zero is not a reliable way to
                get infinity in C. AFAIK compilers are allowed e.g. give a compile-
                time error, and some, such as sdcc, do. AFAIK, C implementations
                are not even required to support infinity. In C99 the macro isinf()
                could replace the first use of division by zero. Unfortunately, the
                macro INFINITY from math.h probably can't replace the second division
                by zero, since it will result in a compile-time diagnostic, if the
                implementation does not support infinity."
  Status:       Open
  Priority:

  Title:       OLD dtoa NEEDS TO BE UPDATED
  Description: This implementation of dtoa in libc/stdio is old and will not
               work with some newer compilers.  See
               http://patrakov.blogspot.com/2009/03/dont-use-old-dtoac.html
  Status:      Open
  Priority:    ??

  Title:       FLOATING POINT FORMATS
  Description: Only the %f floating point format is supported.  Others are accepted
               but treated like %f.
  Status:      Open
  Priority:    Medium (this might important to someone).

  Title:       FLOATING POINT PRECISION
  Description: A fieldwidth and precision is required with the %f format.  If %f
               is used with no format, than floating numbers will be printed with
               a precision of 0 (effectively presented as integers).
  Status:      Open
  Priority:    Medium (this might important to someone).

  Title:       LIBM INACCURACIES
  Description: "..if you are writing something like robot control or
               inertial navigation system for aircraft, I have found
               that using the toolchain libmath is only safe option.
               I ported some code for converting quaternions to Euler
               angles to NuttX for my project and only got it working
               after switching to newlib math library.

               "NuttX does not fully implement IEC 60559 floating point
               from C99 (sections marked [MX] in OpenGroup specs) so if
               your code assumes that some function, say pow(), actually
               behaves right for all the twenty or so odd corner cases
               that the standards committees have recently specified,
               you might get surprises. I'd expect pow(0.0, 1.0) to
               return 0.0 (as zero raised to any positive power is
               well-defined in mathematics) but I get +Inf.

               "NuttX atan2(-0.0, -1.0) returns +M_PI instead of correct
               -M_PI. If we expect [MX] functionality, then atan2(Inf, Inf)
               should return M_PI/4, instead NuttX gives NaN.

               "asin(2.0) does not set domain error or return NaN. In fact
               it does not return at all as the loop in it does not
               converge, hanging your app.

               "There are likely many other issues like these as the Rhombs
               OS code has not been tested or used that much. Sorry for not
               providing patches, but we found it easier just to switch the
               math library."

               Ref: https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/7805
Status:        Open
Priority:      Low for casual users but clearly high if you need care about
               these incorrect corner case behaviors in the math libraries.

o File system / Generic drivers (fs/, drivers/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  NOTE:  The NXFFS file system has its own TODO list at nuttx/fs/nxffs/README.txt

  Title:       CHMOD() AND TRUNCATE()
  Description: Implement chmod(), truncate().
  Status:      Open
  Priority:    Low

  Title:       CAN POLL SUPPORT
  Description: At present, the CAN driver does not support the poll() method.
               See drivers/can.c
  Status:      Open
  Priority:    Low

  Title:       ROMFS CHECKSUMS
  Description: The ROMFS file system does not verify checksums on either
               volume header on on the individual files.
  Status:      Open
  Priority:    Low.  I have mixed feelings about if NuttX should pay a
               performance penalty for better data integrity.

  Title:       SPI-BASED SD MULTIPLE BLOCK TRANSFERS
  Description: The simple SPI based MMCS/SD driver in fs/mmcsd does not
               yet handle multiple block transfers.
  Status:      Open
  Priority:    Medium-Low

  Title:       SDIO-BASED SD READ-AHEAD/WRITE BUFFERING INCOMPLETE
  Description: The drivers/mmcsd/mmcsd_sdio.c driver has hooks in place to
               support read-ahead buffering and write buffering, but the logic
               is incomplete and untested.
  Status:      Open
  Priority:    Low

  Title:       POLLHUP SUPPORT
  Description: All drivers that support the poll method should also report
               POLLHUP event when the driver is closed.
  Status:      Open
  Priority:    Medium-Low

  Title:       CONFIG_RAMLOG_CONSOLE DOES NOT WORK
  Description: When I enable CONFIG_RAMLOG_CONSOLE, the system does not come up
               properly (using configuration stm3240g-eval/nsh2).  The problem
               may be an assertion that is occurring before we have a console.
  Status:      Open
  Priority:    Medium

  Title:       UNIFIED DESCRIPTOR REPRESENTATION
  Descripton:  There are two separate ranges of descriptors for file and
               socket descriptors: if a descriptor is in one range then it is
               recognized as a file descriptor; if it is in another range
               then it is recognized as a socket descriptor.  These separate
               descriptor ranges can cause problems, for example, they makes
               dup'ing descriptors with dup2() problematic.  The two groups
               of descriptors are really indices into two separate tables:
               On an array of file structures and the other an array of
               socket structures.  There really should be one array that
               is a union of file and socket descriptors.  Then socket and
               file descriptors could lie in the same range.
  Status:      Open
  Priority:    Low

  Title:       DUPLICATE FAT FILE NAMES
  Description: "The NSH and POSIX API interpretations about sensitivity or
               insensitivity to upper/lowercase file names seem to be not
               consistent in our usage - which can result in creating two
               directories with the same name..."

               Example using NSH:

                 nsh> echo "Test1" >/tmp/AtEsT.tXt
                 nsh> echo "Test2" >/tmp/aTeSt.TxT
                 nsh> ls /tmp
                 /tmp:
                  AtEsT.tXt
                  aTeSt.TxT
                 nsh> cat /tmp/aTeSt.TxT
                 Test2
                 nsh> cat /tmp/AtEsT.tXt
                 Test1

  Status:      Open
  Priority:    Low

  Title:       FAT LONG FILENAME COMPATIBILTY
  Description: Recently there have been reports that file with long file
               names created by NuttX don't have long file names when viewed
               on Windows.  The long file name support has been around for a
               long time and I don't ever having seen this before so I am
               suspecting that some evil has crept in.
  Status:      Open
  Priority:    Medium

  Title:       MISSING FILES IN NSH 'LS' OF A DIRECTORY
  Description: I have seen cases where (1) long file names are enabled,
               but (2) a short file name is created like:

                 nsh> echo "This is another thest" >/mnt/sdcard/another.txt

               But then on subsequent 'ls' operations, the file does not appear:

                 nsh> ls -l /mnt/sdcard

               I have determined that the problem is because, for some as-
               of-yet-unkown reason the short file name is treated as a long
               file name.  The name then fails the long filename checksum
               test and is skipped.

               readdir() (and fat_readdir()) is the logic underlying the
               failure and the problem appears to be something unique to the
               fat_readdir() implementation.  Why?  Because the file is
               visible when you put the SD card on a PC and because this
               works fine:

                 nsh> ls -l /mnt/sdcard/another.txt

               The failure does not happen on all short file names.  I do
               not understand the pattern.  But I have not had the opportunity
               to dig into this deeply.
  Status:      Open
  Priority:    Perhaps not a problem???  I have analyzed this problem and
               I am not sure what to do about it.  I am suspected that a
               fat filesystem was used with a version of NuttX that does
               not support long file name entries.  Here is the failure
               scenario:

               1) A file with a long file name is created under Windows.
               2) Then the file is deleted.  I am not sure if Windows or
                  NuttX deleted the file, but the resulting directory
                  content is not compatible with NuttX with long file
                  name support.

                  The file deletion left the full sequence of long
                  file name entries intact but apparently delete only
                  the following short file name entry.  I am thinking
                  that this might have happened because a version of NuttX
                  with only short file name support was used to delete
                  the file.

               3) When a new file with a short file name was created, it
                  re-used the short file name entry that was previously
                  deleted.  This makes the new short file name entry
                  look like a part of the long file name.

               4) When comparing the checksum in the long file name
                  entry with the checksum of the short file name, the
                  checksum fails and the entire directlry sequence is
                  ignored by readder() logic.  This the file does not
                  appear in the 'ls'.

o Graphics subsystem (graphics/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  See also the NxWidgets TODO list file for related issues.

  Title:       UNTESTED GRAPHICS APIS
  Description: Testing of all APIs is not complete.  See
               http://nuttx.sourceforge.net/NXGraphicsSubsystem.html#testcoverage
  Status:      Open
  Priority:    Medium

  Title:       ITALIC FONTS / NEGATIVE FONT OFFSETS
  Description: Font metric structure (in include/nuttx/nx/nxfont.h) should allow
               negative X offsets. Negative x-offsets are necessary for certain
               glyphs (and is very common in italic fonts).
               For example Eth, icircumflex, idieresis, and oslash should have
               offset=1 in the 40x49b font (these missing negative offsets are
               NOTE'ed in the font header files).
  Status:      Open.  The problem is that the x-offset is an unsigned bitfield
               in the current structure.
  Priority:    Low.

  Title:       RAW WINDOW AUTORAISE
  Description: Auto-raise only applies to NXTK windows. Shouldn't it also apply
               to raw windows as well?
  Status:      Open
  Priority:    Low

  Title:       AUTO-RAISE DISABLED
  Description: Auto-raise is currently disabled in NX multi-server mode.  The
               reason is complex:
               - Most touchscreen controls send touch data a high rates
               - In multi-server mode, touch events get queued in a message
                  queue.
               - The logic that receives the messages performs the auto-raise.
                 But it can do stupid things after the first auto-raise as
                 it operates on the stale data in the message queue.
               I am thinking that auto-raise ought to be removed from NuttX
               and moved out into a graphics layer (like NxWM) that knows
               more about the appropriate context to do the autoraise.
  Status:      Open
  Priority:    Medium low

  Title:       IMPROVED NxTERM FONT CACHING
  Description: Now each NxTerm instance has its own private font cache
               whose size is determined by CONFIG_NXTERM_MXCHARS.  If there
               are multiple NxTerm instances using the same font, each will
               have a separate font cache.  This is inefficient and wasteful
               of memory:  Each NxTerm instance should share a common font
               cache.
  Status:      Open
  Priority:    Medium.  Not important for day-to-day testing but would be
               a critical improvement if NxTerm were to be used in a
               product.

  Title:       NxTERM VT100 SUPPORT
  Description: If the NxTerm will be used with the Emacs-like command line
               editor (CLE), then it will need to support VT100 cursor control
               commands.
  Status:      Open
  Priority:    Low, the need has not yet arisen.

  Title:       ANTI-ALIASING
  Description: Needed for proper rendering.  After some analysis, I believe
               this change would only be required in the the trapezoid
               rendering logic.  Essentially, it would need to blend the
               fractional pixels at ends of each run with the underlying
               pixel.

               Hmmm.. graphics are sometimes erased by just redrawing them
               with the background color.  Would this approach leave ghost
               images around where the erase image was?
  Status:      Open
  Priority:    Medium-ish.  This would definitely improve graphics rendering
               and line drawing.

  Title:       PER-WINDOW FRAMEBUFFERS
  Description: One of the most awkard things to handle in the NX windowing
               system is the re-draw callback.  This is difficult because it
               requires ad hoc, custom logic to be able to do the redrawing
               in most cases.

               One solution would be to provide a per-window framebuffer.
               All rending would be performed into the per-window framebuffer
               and the rended bits would be copied the LCD or framebuffer
               device memory on demand when the redraw is required.

               This would (a) greatly simplify the graphics interface, (b)
               greatly improve redraw performance, and (c) enable a more
               generic use of the windowing.  The downside would be a large
               usage of memory to hold all of the framebuffers, one for each
               window.
  Status:      Open
  Priority:    Low, of mostly strategic value.

o Pascal Add-On (pcode/)
  ^^^^^^^^^^^^^^^^^^^^^^

  Title:       P-CODES IN MEMORY UNTESTED
  Description: Need APIs to verify execution of P-Code from memory buffer.
  Status:      Open
  Priority:    Low

  Title:       SMALLER LOADER AND OBJECT FORMAT
  Description: Loader and object format may be too large for some small
               memory systems.  Consider ways to reduce memory footprint.
  Status:      Open
  Priority:    Medium

  Title:       PDBG
  Description: Move the the pascal p-code debugger into the NuttX apps/ tree
               where it can be used from the NSH command line.
  Status:      Open
  Priority:    Low

o Build system
  ^^^^^^^^^^^^

  Title:       WINDOWS DEPENDENCY GENERATION
  Description: Dependency generation is currently disabled when a Windows native
               toolchain is used in a POSIX-like environment (like Cygwin).  The
               issue is that the Windows tool generates dependencies use Windows
               path formatting and this fails with the dependency file (Make.dep)
               is include).  Perhaps the only issue is that all of the Windows
               dependencies needed to be quoted in the Make.dep files.
  Status:      Open
  Priority:    Low -- unless some dependency-related build issues is discovered.

  Title:       MAKE EXPORT LIMITATIONS
  Description: The top-level Makefile 'export' target that will bundle up all of the
               NuttX libraries, header files, and the startup object into an export-able
               tarball. This target uses the tools/mkexport.sh script.  Issues:

               1. This script assumes the host archiver ar may not be appropriate for
                  non-GCC toolchains
               2. For the kernel build, the user libraries should be built into some
                  libuser.a.  The list of user libraries would have to accepted with
                  some new argument, perhaps -u.
  Status:      Open
  Priority:    Low.

o Linux/Cywgin simulation (arch/sim)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       SIMULATOR NETWORKING SUPPORT
  Description: I never did get networking to work on the sim Linux target.  On Linux,
               it tries to use the tap device (/dev/net/tun) to emulate an Ethernet
               NIC, but I never got it correctly integrated with the NuttX networking.
               NOTE: On Cygwin, the build uses the Cygwin WPCAP library and is, at
               least, partially functional (it has never been rigorously tested).
  Status:      Open
  Priority:    Low (unless you want to test networking features on the simulation).

  Title:       SIMULATOR HAS NO INTERRUPTS (NON-PREMPTIBLE)
  Description: The current simulator implementation is has no interrupts and, hence,
               is non-preemptible.  Also, without simulated interrupt, there can
               be no high-fidelity simulated device drivers.

               Currently, all timing and serial input is simulated in the IDLE loop:
               When nothing is going on in the simulation, the IDLE loop runs and
               fakes timer and UART events.
  Status:      Open
  Priority:    Low, unless there is a need for developing a higher fidelity simulation
               I have been thinking about how to implement simulated interrupts in
               the simulation.  I think a solution would work like this:
               http://www.nuttx.org/doku.php?id=wiki:nxinternal:simulator

  Title:       ROUND-ROBIN SCHEDULING IN THE SIMULATOR
  Description: Since the simulation is not pre-emptible, you can't use round-robin
               scheduling (no time slicing).  Currently, the timer interrupts are
               "faked" during IDLE loop processing and, as a result, there is no
               task pre-emption because there are no asynchronous events.  This could
               probably be fixed if the "timer interrupt" were driver by Linux
               signals. NOTE:  You would also have to implement irqsave() and
               irqrestore() to block and (conditionally) unblock the signal.
  Status:      Open
  Priority:    Low

o ARM (arch/arm/)
  ^^^^^^^^^^^^^^^

  Title:       IMPROVED ARM INTERRUPT HANDLING
  Description: ARM interrupt handling performance could be improved in some
               ways. One easy way is to use a pointer to the context save
               area in current_regs instead of using up_copystate so much.

               This approach is already implemented for the ARM Cortex-M0,
               Cortex-M3, Cortex-M4, and Cortex-A5 families.  But still needs
               to be back-ported to the ARM7 and ARM9 (which are nearly
               identical to the Cortex-A5 in this regard).  The change is
               *very* simple for this architecture, but not implemented.
  Status:      Open.  But complete on all ARM platforms except ARM7 and ARM9.
  Priority:    Low.

  Title:       IMPROVED ARM INTERRUPT HANDLING
  Description: The ARM and Cortex-M3 interrupt handlers restores all registers
               upon return. This could be improved as well:  If there is no
               context switch, then the static registers need not be restored
               because they will not be modified by the called C code.
               (see arch/sh/src/sh1/sh1_vector.S for example)
  Status:      Open
  Priority:    Low

  Title:       CORTEX-M3 STACK OVERFLOW
  Description: There is bit bit logic in up_fullcontextrestore() that executes on
               return from interrupts (and other context switches) that looks like:

                 ldr r1, [r0, #(4*REG_CPSR)] /* Fetch the stored CPSR value */
                 msr cpsr, r1 /* Set the CPSR */

                 /* Now recover r0 and r1 */

                 ldr r0, [sp]
                 ldr r1, [sp, #4]
                 add sp, sp, #(2*4)

                 /* Then return to the address at the stop of the stack,
                  * destroying the stack frame
                  */

                 ldr pc, [sp], #4

               Under conditions of excessively high interrupt conditions, many
               nested interrupts can occur just after the 'msr cpsr' instruction.
               At that time, there are 4 bytes on the stack and, with each
               interrupt, the stack pointer may increment and possibly overflow.

               This can happen only under conditions of continuous interrupts.
               See this email thread: https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/1261
               On suggested change is:

                 ldr  r1, [r0, #(4*REG_CPSR)] /* Fetch the stored CPSR value */
                 msr spsr_cxsf, r1 /* Set the CPSR */
                 ldmia     r0, {r0-r15}^

               But this has not been proven to be a solution.

               UPDATE:  Other ARM architectures have a similer issue.

  Status:      Open
  Priority:    Low.  The conditions of continuous interrupts is really the problem.
               If your design needs continuous interrupts like this, please try
               the above change and, please, submit a patch with the working fix.

  Title:       STACK ALIGNMENT IN INTERRUPT HANDLERS
  Description: The EABI standard requires that the stack always have a 32-byte
               alignment.  There is no guarantee at present that the stack will be
               so aligned in an interrupt handler.  Therefore, I would expect some
               issues if, for example, floating point or perhaps long long operations
               were performed in an interrupt handler.

               This issue exists for ARM7, ARM9, Cortex-M0, Cortex-M3, and
               Cortex-M4 but has been addressed for the Cortex-A5.  The fix
               is really simple can cannot be incorporated without some
               substantial testing.  For ARM, the fix is the following logic
               arround each call into C code from assembly:

                 mov  r4, sp     /* Save the SP in a preserved register */
                 bic  sp, sp, #7 /* Force 8-byte alignment */
                 bl   cfunction  /* Call the C function */
                 mov  sp, r4     /* Restore the possibly unaligned stack pointer */

               This same issue applies to the interrupt stack which is, I think
               improperly aligned in almost all cases (except Cortex-A5).

  Status:      Open
  Priority:    Low for me because I never do floating point operations in
               interrupt handlers.

  Title:       IMPROVED TASK START-UP AND SYSCALL RETURN
  Description: Couldn't up_start_task and up_start_pthread syscalls be
               eliminated.  Wouldn't this work to get us from kernel-
               to user-mode with a system trap:

                 lda r13, #address
                 str rn, [r13]
                 msr spsr_SVC, rm
                 ld r13,{r15}^

               Would also need to set r13_USER and r14_USER. For new
               SYS_context_switch... couldn't we do he same thing?

               Also... System calls use traps to get from user- to kernel-
               mode to perform OS services.  That is necessary to get from
               user- to kernel-mode.  But then another trap is used to get
               from kernel- back to user-mode.  It seems like this second
               trap should be unnecessary.  We should be able to do the
               same kind of logic to do this.
  Status:      Open
  Priority:    Low-ish, but a good opportunity for performance improvement.

o ARM/C5471 (arch/arm/src/c5471/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       UART RECONFIGURATION
  Description: UART re-configuration is untested and conditionally compiled out.
  Status:      Open
  Priority:    Medium.  ttyS1 is not configured, but not used; ttyS0 is configured
               by the bootloader

o ARM/DM320 (arch/arm/src/dm320/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       DEBUG ISSUES
  Description: config/ntos-dm320: It seems that when a lot of debug statements
               are added, the system no longer boots.  This is suspected to be
               a stack problem: Making the stack bigger or removing arrays on
               the stack seems to fix the problem (might also be the
               bootloader overwriting memory)
  Status:      Open
  Priority:    Medium

  Title:       USB DEVICE DRIVER UNTESTED
  Description: A USB device controller driver was added but has never been tested.
  Status:      Open
  Priority:    Medium

  Title:       FRAMEBUFFER DRIVER UNTESTED
  Description: A framebuffer "driver" was added, however, it remains untested.
  Status:      Open
  Priority:    Medium

  Title:       VIDEO ENCODER DRIVER
  Description: In order to use the framebuffer "driver" additional video encoder
               logic is required to setup composite video output or to interface
               with an LCD.
  Status:      Open
  Priority:    Medium (high if you need to use the framebuffer driver)

o ARM/i.MX (arch/arm/src/imx/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       PORT IS INCOMPLETE
  Description: The basic port of the i.MX1 architecture was never finished.  The port
               is incomplete (as of this writing, is still lacks a timer, interrupt
               decoding, USB, network) and untested.
  Status:      Open
  Priority:    Medium (high if you need i.MX1/L support)

  Title:       SPI METHODS ARE NOT THREAD SAFE
  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
  Status:      Open
  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.

o ARM/LPC17xx (arch/arm/src/lpc17xx/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       USB DMA INCOMPLETE
  Description: USB DMA not fully implemented. Partial logic is in place but it is
               fragmentary and bogus. (Leveraged from the lpc214x)
  Status:      Open
  Priority:    Low

  Title:       SSP DRIVER IMPROVEMENTS
  Description: a) At present the SSP driver is polled.  Should it be interrupt driven?
                  Look at arch/arm/src/imx/imx_spi.c -- that is a good example of an
                  interrupt driven SPI driver.  Should be very easy to part that architecture
                  to the LPC.
               b) See other SSP (SPI) driver issues listed under ARM/LPC214x.  The LPC17xx
                  driver is a port of the LPC214x driver and probably has the same issues.
               b) Other SSP driver improvements: Add support for multiple devices on the
                  SSP bus, use DMA data transfers
  Status:      Open
  Priority:    Medium

  Title:       NOKIA LCD DRIVER NONFUNCTIONAL
  Description: An LCD driver for the Olimex LPC1766STK has been developed.  However, that
               driver is not yet functional on the board:  The backlight comes on, but
               nothing is visible on the display.
  Status:      Open
  Priority:    Medium-Low (unless you need the display on the LPC1766STK!)

o ARM/LPC214x (arch/arm/src/lpc214x/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       VECTOR INTERRUPTS
  Description: Should use Vector Interrupts
  Status:      Open
  Priority:    Low

  Title:       USB DMA INCOMPLETE
  Description: USB DMA not fully implemented. Partial logic is in place but it is
               fragmentary and bogus.
  Status:      Open
  Priority:    Low

  Title:       USB SERIAL DRIVER REPORTS WRONG ERROR
  Description: USB Serial Driver reports wrong error when opened before the
               USB is connected (reports EBADF instead of ENOTCONN)
  Status:      Open
  Priority:    Low

  Title:       SPI DRIVER IMPROVEMENTS
  Description: At present the SPI driver is polled.  Should it be interrupt driven?
               Look at arch/arm/src/imx/imx_spi.c -- that is a good example of an
               interrupt driven SPI driver.  Should be very easy to part that architecture
               to the LPC.
  Status:      Open
  Priority:    Medium

  Title:       SPI METHODS ARE NOT THREAD SAFE
  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
  Status:      Open
  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.

  Title:       SPI DRIVER DELAYS
  Description: At present the SPI driver is polled -AND- there is a rather large, arbitrary,
               delay in one of the block access routines.  The purpose of the delay is to
               avoid a race conditions.  This begs for a re-design -OR- at a minimum, some
               optimization of the delay time.
  Status:      Open
  Priority:    Medium

  Title:       2GB SD CARD ISSUES
  Desription:  I am unable to initialize a 2Gb SanDisk microSD card (in adaptor) on the
               the mcu123 board.  The card fails to accept CMD0.  Doesn't seem like a software
               issue, but if anyone else sees the problem, I'd like to know.
               Related:  Fixes were recently made for the SDIO-based MMC/SD driver to
               support 2Gb cards -- the block size was forced to 512 in all cases.  The SPI-
               based driver may also have this problem (but I don't think this would have
               anything to do with CMD0).
  Status:      Open
  Priority:    Uncertain

  Title:       USB BROKEN?
  Description: I tried to bring up the new configuration at configs/mcu123-214x/composite,
               and Linux failed to enumerate the device.  I don't know if this is
               a problem with the lpc214x USB driver (bit rot), or due to recent
               changed (e.g., -r4359 is suspicious), or an incompatibility between the
               Composite driver and the LPC214x USB driver.  It will take more work
               to find out which -- like checking if the other USB configurations are
               also broken.
  Status:      Open
  Priority:    It would be high if the LPC2148 were a current, main stream architecture.
               I am not aware of anyone using LPC2148 now so I think the priority has
               to be low.

o ARM/LPC31xx (arch/arm/src/lpc31xx/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       PLATFORM-SPECIFIC LOGIC
  Description: arch/arm/src/lpc313x/lpc313x_spi.c contains logic that is specific to the
               Embedded Artist's ea3131 board.  We need to abstract the assignment of SPI
               chip selects and logic SPI functions (like SPIDEV_FLASH).  My thoughts are:
               - Remove lpc313x_spiselect and lpc313x_spistatus from lpc313x_internal.h
               - Remove configs/ea3131/src/up_spi.c
               - Add configurations CONFIG_LPC3131x_CSOUT1DEV, CONFIG_LPC3131x_CSOUT2DEV,
                 and CONFIG_LPC3131x_CSOUT3DEV that maps the lpc313x SPI chip selects to
                 SPIDEV_* values.
               - Change arch/arm/src/lpc313x/lpc313x_spi.c to use those configuration
                 settings.
  Status:      Open
  Priority:    High if you want to use SPI on any board other than the ea3131.

  Title:       SPI DRIVER
  Description: arch/arm/src/lpc313x/lpc313x_spi.c may or may not be functional.  It was
               reported to be working, but I was unable to get it working with the
               Atmel at45dbxx serial FLASH driver.
  Status:      Open
  Priority:    High if you need to use SPI.

o ARM/LPC43x (arch/arm/src/lpc43xx/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  See comments in configs/lpc4330-xplorer/README.txt

o ARM/STR71x (arch/arm/src/str71x/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       UNVERIFIED MMC SUPPORT
  Description: Verify SPI driver and integrate with MMC support. This effort is stalled
               at the moment because the slot on the Olimex board only accepts MMC card;
               I have no MMC cards, only SD cards which won't fit into the slot.
  Status:      Open
  Priority:    Medium

  Title:       SPI METHODS ARE NOT THREAD SAFE
  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
  Status:      Open
  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.

o ARM/LM3S6918 (arch/arm/src/tiva/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       SSI OVERRUNS
  Description: Should terminate SSI/SPI transfer if an Rx FIFO overrun occurs.
               Right now, if an Rx FIFO overrun occurs, the SSI driver hangs.
  Status:      Open
  Priority:    Medium, If the transfer is properly tuned, then there should not
               be any Rx FIFO overruns.

  Title:       THTTPD BUGS
  Description: There are some lingering bugs in THTTPD, possibly race conditions.  This
               is covered above under Network Utilities, but is duplicated here
               to point out that the LM3S suffers from this bug.
  Status:      Open.
               UPDATE: I have found that increasing the size of the CGI program stack
               from 1024 to 2048 (on the LM3S) eliminates the problem.  So the most
               likely cause is probably a stack overflow, not a hard software bug.
  Priority:    Probably Low

o ARM/SAMA5D3 ((arch/arm/src/sama5/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Issues related to the SAMA5D3 port are in configs/sama5d3x-ek/README.txt.
  Issues related to the SAMA5D4 port are in configs/sama5d4-ek/README.txt.

o ARM/SAMV7 ((arch/arm/src/samv7/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Issues related to the SAMA5D3 port are in configs/samv71-xult/README.txt.

o ARM/STM32 (arch/arm/src/stm32/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       USBSERIAL ISSUES
  Description  A USB device-side driver is in place but not well tested.  At
               present, the apps/examples/usbserial test sometimes fails.  The situation
               that causes the failure is:

               - Host-side of the test started after the target side sends the
                 first serial message.

               The general failure is as follows:

               - The target message pends in the endpoint packet memory
               - When the host-side of the test is stated, it correctly
                 reads this pending data.
               - an EP correct transfer interrupt occurs and the next
                 pending outgoing message is setup
               - But, the host never receives the next message

               If the host-side driver is started before the first target message
               is sent, the driver works fine.
  Status:      Open
  Priority:    Medium-High

  Title:       DMA EXTENSIONS F1/3
  Description: DMA logic needs to be extended.  DMA2, Channel 5, will not work
               because the DMA2 channels 4 & 5 share the same interrupt.
  Status:      Open
  Priority:    Low until someone needs DMA1, Channel 5 (ADC3, UART4_TX, TIM5_CH1, or
               TIM8_CH2).

  Title:       F4 SDIO MULTI-BLOCK TRANSFER FAILURES
  Description: If you use a large I/O buffer to access the file system, then the
               MMCSD driver will perform multiple block SD transfers.  With DMA
               ON, this seems to result in CRC errors detected by the hardware
               during the transfer.  Workaround:  CONFIG_MMCSD_MULTIBLOCK_DISABLE=y.
  Status:      Open
  Priority:    Medium

  Title:       DMA BOUNDARY CROSSING
  Description: I see this statement in the reference manual:  "The burst
               configuration has to be selected in order to respect the AHB protocol,
               where bursts must not cross the 1 KB address boundary because the
               minimum address space that can be allocated to a single slave
               is 1 KB. This means that the 1 KB address boundary should not be crossed
               by a burst block transfer, otherwise an AHB error would be generated,
               that is not reported by the DMA registers."

               The implication is that there may be some unenforced alignment
               requirements for some DMAs.  There is nothing in the DMA driver to
               prevent this now.
  Status:      Open
  Priority:    Low (I am not even sure if this is a problem yet).

  Title:       DMA FROM EXTERNAL, FSMC MEMORY
  Description: I have seen a problem on F1 where all SDIO DMAs work exist for
               write DMAs from FSMC memory (i.e., from FSMC memory to SDIO).
               Read transfers work fine (SDIO to FSMC memory).  The failure is
               a data underrun error with zero bytes of data transferred.  The
               workaround for now is to use DMA buffers allocated from internal
               SRAM.
  Status:      Open
  Priority:    Low

o AVR (arch/avr)
  ^^^^^^^^^^^^^^

  Title:        AMBER WEB SERVER UNTESTED
  Description:  There is a port for the Amber Web Server ATMega128, however this is
                completely untested due to the lack to compatible, functional test
                equipment.
  Status:       Open
  Priority:     The priority might as well be low since there is nothing I can do about
                it anyway.

  Title:        STRINGS IN RAM
  Description:  Many printf-intensive examples (such as the OS test) cannot be executed
                on most AVR platforms.  The reason is because these tests/examples
                generate a lot of string data.  The build system currently places all
                string data in RAM and the string data can easily overflow the tiny
                SRAMs on these parts.  A solution would be to put the string data
                into the more abundant FLASH memory, but this would require modification
                to the printf logic to access the strings from program memory.
  Status:       Open
  Priority:     Low.  The AVR is probably not the architecture that you want to use
                for extensive string operations.

  Title:        SPI AND USB DRIVERS UNTESTED
  Description:  An SPI driver and a USB device driver exist for the AT90USB (as well
                as a USB mass storage example).  However, this configuration is not
                fully debugged as of the NuttX-6.5 release.
                Update 7/11:  (1) The SPI/SD driver has been verified, however, (2) I
                believe that the current teensy/usbmsc configuration uses too
                much SRAM for the system to behave sanely.  A lower memory footprint
                version of the mass storage driver will be required before this can
                be debugged
  Status:       Open
  Priority:     Medium-High.

  Title:        AVR32 PORT IS NOT FULLY TESTED
  Description:  A complete port for the AVR32 is provided and has been partially
                debugged.  There may still be some issues with the serial port
                driver.
  Status:       Open
  Priority:     Medium

o Intel x86 (arch/x86)
  ^^^^^^^^^^^^^^^^^^^^

o MIPS/PIC32(arch/mips)
  ^^^^^^^^^^^^^^^^^^^^^

  Title:       PIC32 USB DRIVER DOES NOT WORK WITH MASS STORAGE CLASS
               UPDATE:  ** ONLY USING RAM DISK FOR EXPORTED VOLUME ***
  Description: The PIC32 USB driver either crashes or hangs when used with
               the mass storage class when trying to write files to the target
               storage device.  This usually works with debug on, but does not
               work with debug OFF (implying some race condition?)

               Here are some details of what I see in debugging:

               1. The USB MSC device completes processing of a read request
                  and returns the read request to the driver.
               2. Before the MSC device can even begin the wait for the next
                  driver, many packets come in at interrupt level.  The MSC
                  device goes to sleep (on pthread_cond_wait) with all of the
                  read buffers ready (16 in my test case).
               3. The pthread_cond_wait() does not wake up.  This implies
                  a problem with pthread_con_wait(?).  But in other cases,
                  the MSC device does wake up, but then immediately crashes
                  because its stack is bad.
               4. If I force the pthread_cond_wait to wake up (by using
                  pthread_cond_timedwait instead), then the thread wakes
                  up and crashes with a bad stack.

               So far, I have no clue why this is failing.

               UPDATE:  This bug was recorded using the PIC32 Ethernet
               Starter kit with a RAM disk (that board has no SD card slot).
               However, using the USB mass storage device with the
               Mikroelektronika using a real SD card, there is no such
               problem -- the mass storage device seems quite stable.

               UPDATE:  Hmmm.. retesting with the Mikroelektronika board
               shows problems again.  I think that there are some subtle
               timing bugs whose effects can very from innocuous to severe.
  Status:      Open
  Priority:    Originally, High BUT reduced to very Low based on the
               UPDATED comments.

  Title:       PIC32 USB MASS STORAGE DEVICE FAILS TO RE-CONNECT
  Description: Found using configuration configs/pic32mx7mmb/nsh.
               In this configuration, the NSH 'msconn' command will connect the
               mass storage device to the host; the 'msdis' command will
               disconnect the device.  The first 'msconn' works perfectly.
               However, when attempting to re-connect, the second 'msconn'
               command does not command properly:  Windows reports an
               unrecognized device.  Apparently, some state is being properly
               reset when the mass storage device is disconnected.  Shouldn't
               be hard to fix.
  Status:      Open
  Priority:    Medium

  Title:       POSSIBLE INTERRUPT CONTROL ISSUE
  Description: There is a kludge in the file arch/mips/src/common/up_idle.c.
               Basically, if there is nothing else going on in the IDLE loop,
               you have to disable then re-enable interrupts.  Logically nothing
               changes, but if you don't do this interrupts will be be disabled
               in the IDLE loop which is a very bad thing to happen.

               Some odd behavior in the interrupt setup on the IDLE loop is
               not really a big concern, but what I do not understand is if
               this behavior is occurring on all threads after all context
               switches:  Are interrupts always disabled until re-enabled?
               This requires some further investigation at some point; it
               may be nothing but may also be a symptom of some changes
               required to the interrupt return logic (perhaps some CP0
               status hazard?)
  Status:      Open
  Priority:    Low. Puzzling and needs some investigation, but there there
               is no known misbehavior.

o Hitachi/Renesas SH-1 (arch/sh/src/sh1)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:        SH-1 IS UNUSABLE
  Description:  There are instabilities that make the SH-1 port un-usable.  The
                nature of these is not understood; the behavior is that certain SH-1
                instructions stop working as advertised.  I have seen the following
                examples:

                  412b jmp @r1 - Set a return address in PR, i.e., it behaved like
                       410b jsr @r1.  Normally 412b works correctly, but in the failure
                       condition, it reliably set the PR.
                  69F6 mov.l @r15+,r9 - wrote the value of R1 to @r15+.  This behavior
                       does not correspond to any known SH-1 instruction

                This could be a silicon problem, some pipeline issue that is not
                handled properly by the gcc 3.4.5 toolchain (which has very limit
                SH-1 support to begin with), or perhaps with the CMON debugger.  At
                any rate, I have exhausted all of the energy that I am willing to put
                into this cool old processor for the time being.

                Update:  This bug will probably never be addressed now.  I just
                cleaned house and my old SH-1 was one of the things that went.

  Status:       Open
  Priority:     Low -- because the SH-1, SH7032, is very old and only of historical
                interest.

o Renesas M16C/26 (arch/sh/src/m16c)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:        M16C DOES NOT BUILD
  Description:  The M16C target cannot be built.  The GNU m16c-elf-ld link fails with
                the following message:

                m32c-elf-ld: BFD (GNU Binutils) 2.19 assertion fail /home/Owner/projects/nuttx/buildroot/toolchain_build_m32c/binutils-2.19/bfd/elf32-m32c.c:482

                Where the reference line is:

                /* If the symbol is out of range for a 16-bit address,
                   we must have allocated a plt entry.  */
                BFD_ASSERT (*plt_offset != (bfd_vma) -1);

                No workaround is known at this time.
  Status:       Open
  Priority:     High -- this is a show stopper for M16C.

  Title:       M16C PORT UNTESTED
  Description: Coding of the initial port is complete, but is untested.
  Status:      Open
  Priority:    Low

  Title:       NO SERIAL CONNECTOR
  Description: Serial drivers were developed for the M16C, however, the SKP16C26
               StarterKit has no serial connectors.
  Status:      Open
  Priority:    Low

  Title:       UNIMPLEMENTED M16C DRIVERS
  Description: Should implement SPI, I2C, Virtual EEPROM, FLASH, RTC drivers
  Status:      Open
  Priority:    Medium

o z80/z8/ez80/z180 (arch/z80)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       SDCC INTEGER OVERFLOWS
  Description: The SDCC version the same problems with integer overflow during
               compilation for certain 8-bit platform.  At typical cause is code like
               usleep(500*1000) which exceeds the range of a 16-bit integer.
  Status:      These have probably been fixed but have not yet been verified on these
               affected platforms.
  Priority:    Low for now

  Title:       Z80 SIMULATED CONSOLE
  Description: The simulated Z80 serial console (configs/z80sim/src/z80_serial.c +
               driver/serial.c) does not work.  This is because there are
               no interrupts in the simulation so there is never any serial
               traffic.
  Status:      Open
  Priority:    Low -- the simulated console is not critical path and the designs
               to solve the problem are complex.

  Title:       ZDS-II LIBRARIAN WARNINGS
  Description: ZDS-II Librarian complains that the source for the .obj file
               is not in the library.
  Status:      Open
  Priority:    Low, thought to be cosmetic.  I think this is a consequence of
               replacing vs. inserting the library.

  Title:       ZDS-II COMPILER PROBLEMS
  Description: The ZDS-II compiler (version 4.10.1) fails with an internal error
               while compiling mm/mm_initialize.c.  This has been reported as
               incident 81509.

               I have found the following workaround that I use to build for the
               time being:

               --- mm/mm_initialize.c.SAVE    2008-02-13 08:06:46.833857700 -0600
               +++ mm/mm_initialize.c    2008-02-13 08:07:26.367608900 -0600
               @@ -94,8 +94,11 @@
               {
                  int i;

               +#if 0 /* DO NOT CHECK IN */
                  CHECK_ALLOCNODE_SIZE;
                  CHECK_FREENODE_SIZE;
               +#endif

               /* Set up global variables */

  Status:      Open
  Priority:    High

  Title:       EZ8 PRIORITY INTERRUPTS
  Description: Add support for prioritized ez8 interrupts.  Currently logic supports
               only nominal interrupt priority.
  Status:      Open
  Priority:    Low

  Title:       Z8ENCORE ONLY VERIFIED ON SIMULATOR
  Description: The z8Encore! port has only been verified on the ZDS-II instruction
               set simulator.
  Status:      Open
  Priority:    Medium

  Title:       XTRS CLEAN
  Description: The XTRS target (configs/xtrs) has a clean problem. The clean
               rule removes .asm files.  This works because there are no .asm
               files except in sub-directories that are provided from 'make clean' --
               except for XTRS:  It has a .asm file in its src/ directory that
               gets removed every time clean is performed.
  Status:      Open
  Priority:    High if you happen to be working with XTRS.

  Title:       SPI/I2C UNTESTED
  Description: A "generic" SPI and I2C drivers have been coded for the eZ80Acclaim!
               However, these remains untested since I have no SPI or I2C devices for
               the board (yet).
  Status:      Open
  Priority:    Med

  Title:       SPI METHODS ARE NOT THREAD SAFE
  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
  Status:      Open
  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.

  Title:       I2C UNTESTED
  Description: A "generic" I2C driver has been coded for the eZ8Encore!
               However, this remains untested since I have no I2C devices for
               the board (yet).
  Status:      Open
  Priority:    Med

  Title:       UNFINISHED Z180 LOGIC NEEDED BY THE P112 BOARD
  Description: 1) Need to revisit the start-up logic.  Looking at the P112 Bios
                  (Bios.mcd), I see that quite of bit of register setup is done
                  there.
               2) Finish ESCC driver logic.
  Status:      Open
  Priority:    Low (at least until I get P112 hardware)

o z16 (arch/z16)
^^^^^^^^^^^^^^^^

  Title:       ZDS-II LIBRARIAN WARNINGS
  Description: ZDS-II Librarian complains that the source for the .obj file
               is not in the library.
  Status:      Open
  Priority:    Low, thought to be cosmetic.  I think this is a consequence of
               replacing vs. inserting the library.

  Title:       SYSTEM DELAYS
  Description: The system delays do not appear to be correct with the
               apps/examples/ostest/timedmqueue.c test.
  Status:      Open
  Priority:    Medium-High

  Title:       PROBLEMS WHEN DEBUG DISABLED
  Description: At present, the z16f port does not run properly when CONFIG_DEBUG
               is disabled:  The obvious symptom is that there is no printf()
               output.  I have isolated with problem to errors in optimization.
               With -reduceopt on the command line, I can get the printf output.
               However, there are still errors in the compiled code -- specifically
               in sched/timer_create.c.

               I have submitted a bug report to ZiLOG for this (support incident
               81400).  You can see the status of the bug report (and lots more
               technical detail) here:
               http://support.zilog.com/support/incident/incident_support.asp?iIncidentId=81400&iSiteId=1&chLanguageCode=ENG

               Summary of ZiLOG analysis: "This is a ZNEO compiler problem. ... [a] workaround
               is to replace:
                   if ( !timerid || (clockid != 0) )
                By:
                   if ((clockid != 0) || !timerid)"

  Status:      Open
  Priority:    Medium-High

  Title:       PASCAL ADD-ON
  Description: The pascal add-on does not work with the z16f (that is
               configuration z16f2800100zcog/pashello).  This appears to be
               another ZDS-II error:  when executing the instruction
               SYSIO 0, WRITESTR a large case statement is executed.  This
               involves a call into the ZiLOG runtime library to __uwcase().
               __uwcase is passed a pointer to a structure containing jump
               information.  The cause of the failure appears to be that
               the referenced switch data is bad.
               This is submitted as ZiLOG support incident 81459.

               Summary of ZiLOG analysis: "This is a ZNEO run time library problem.
               One workaround is to replace the line 58 in uwcase.asm

               From:
                      ADD       R9,#4             ; Skip handler
               To:
                      ADD       R9,#2             ; Skip handler

               And add uwcase.asm to the project.

               If the customer does not want to modify uwcase.asm then the other
               workaround is to add a dummy case and make it same as default:

               case 0x8000:
               default:

               This will make sure that uwcase is not called but ulcase is called."
  Status:      Open.  Due to licensing issues, I cannot include the modified
               uwcase in the NuttX code base.
  Priority:    Medium

  Title:       USE SPOV
  Description: Add support to maintain SPOV in context switching.  This
               improvement will provide protection against stack overflow
               and make a safer system solution.
  Status:      Open
  Priority:    Low

  Title:       PRIORITIZED INTERRUPTS
  Description: Add support for prioritized interrupts.  Currently logic supports
               only nominal interrupt priority.
  Status:      Open
  Priority:    Low

  Title:       ZDS-II COMPILER PROBLEMS
  Description: The file drivers/mmcsd/mmcsd_sdio.c generates an internal compiler
               error like:

               mmcsd\mmcsd_sdio.c
               Internal Error(0503) On line 2504 of "MMCSD\MMCSD_SDIO.C"
                   File <c3>, Args(562,46)

  Status:      Open.  Recommended workaround: remove mmcsd_sdio.c from
               drivers/mmcsd/Make.defs.  There is no SDIO support for the Z16 anyway
  Priority:    Low

  Title:       NATIVE BUILD PROBLEMS
  Description: When last tested (ca.12/12), there were some missing .obj files in
               arch/z16/src. A little additional TLC will be needed to get a
               reliable Windows native build.
  Status:      Open
  Priority:    Low -- I don't think anyone uses the Z16 port with the native build.

  Title:       COMPILER BUG
  Description: There is a bug in the ZDS II 5.0.1 compiler.  It generates incorrect
               code when calling through a function pointer if (1) the function
               pointer is a field in a structure, and (2) the function pointer has
               a variable number of arguments.

               The exact name of the bug is this:  Normally, when a function is
               called, parameters are passed in registers.  When calling a
               function with a variable number of arguments, parameters must
               instead be passed on the stack.  In this failure case3, parameters
               are erroneously passed in registers while the receive function
               expects the parameters on the stack.  This usually results in a
               crash.

               Unfortunately, NSH does have this exact kind of function call and
               because of this compiler bug, NSH cannot be used with the ZNEO
  Status:      The bug has been reported to ZiLOG and they have reproduced the
               problem.  There is, however, no schedule for correction of the bug.
  Priority:    High if you are using ZNEO

o mc68hc1x (arch/hc)
  ^^^^^^^^^^^^^^^^^^

  Title:       BANKED MODE
  Description: There is no script for building in banked mode (more correctly, there
               is a script, but logic inside the script has not yet been implemented).
               It would be necessary to implement banked mode to able to access more
               the 48K of FLASH.
  Status:      Open.
  Priority:    Medium/Low

o Network Utilities (apps/netutils/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       UNVERIFIED THTTPD FEATURES
  Description: Not all THTTPD features/options have been verified.  In particular, there is no
               test case of a CGI program receiving POST input.  Only the configuration of
               apps/examples/thttpd has been tested.
  Status:      Open
  Priority:    Medium

  Title:       THTTPD WARNINGS
  Description: If the network is enabled, but THTTPD is not configured, it spews out lots
               of pointless warnings.  This is kind of annoying and unprofessional; needs to
               be fixed someday.
  Status:      Open.  An annoyance, but not a real problem.
  Priority:    Low

  Title:       DHCPD ACCESSES KERNEL PRIVATE INTERFACE
  Description: arp_update() is referenced outside of nuttx/net.  It is used in
               in the netutils/ DHCPD logic to set entries in the ARP table.
               That is violation of the separation of kernel and OS
               functionality.  As a consequence, dhcpd will not work with the
               NuttX kernel built.

               This direct OS call needs to be replaced with a network ioctl()
               call.
  Status:      Open
  Priority:    Medium.  Important for full functionality with kernel build.

  Title:       NETWORK MONITOR NOT GENERALLY AVAILABLE
  Description: The NSH network management logic has general applicability
               but is currently useful only because it is embedded in the NSH
               module.  It should be moved to apps/system or, better,
               apps/netutils.
  Status:      Open
  Priority:    Low

o NuttShell (NSH) (apps/nshlib)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       IFCONFIG AND MULTIPLE NETWORK INTERFACES
  Descripton:  The ifconfig command will not behave correctly if an interface
               is provided and there are multiple interfaces.  It should only
               show status for the single interface on the command line; it will
               still show status for all interfaces.
  Status:      Open
  Priority:    Low (multiple network interfaces not fully supported yet anyway).

  Title:       ARP COMMAND
  Description: Add an ARP command so that we can see and modify the contents of
               the ARP table.
  Status:      Open
  Priority:    Low (enhancement)

  Title:       ARPPING COMMAND
  Description: Add an arping command
  Status:      Open
  Priority:    Low (enhancement)

o System libraries apps/system (apps/system)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       READLINE IMPLEMENTATION
  Description: readline implementation does not use C-buffered I/O, but rather
               talks to serial driver directly via read().  It includes VT-100
               specific editing commands.  A more generic readline() should be
               implemented using termios' tcsetattr() to put the serial driver
               into a "raw" mode.
  Status:      Open
  Priority:    Low (unless you are using mixed C-buffered I/O with readline and
               fgetc, for example).

o Other Applications & Tests (apps/examples/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       EXAMPLES/PIPE ON CYGWIN
  Description: The redirection test (part of examples/pipe) terminates
               incorrectly on the Cywgin-based simulation platform (but works
               fine on the Linux-based simulation platform).
  Status:      Open
  Priority:    Low

  Title:       EXAMPLES/SENDMAIL UNTESTED
  Description: examples/sendmail is untested on the target (it has been tested
               on the host, but not on the target).
  Status:      Open
  Priority:    Med

  Title:       EXAMPLES/NX FONT CACHING
  Description: The font caching logic in examples/nx is incomplete.  Fonts are
               added to the cache, but never removed.  When the cache is full
               it stops rendering.  This is not a problem for the examples/nx
               code because it uses so few fonts, but if the logic were
               leveraged for more general purposes, it would be a problem.
               Update: see examples/nxtext for some improved font cache handling.
  Status:      Open
  Priority:    Low.  This is not really a problem because examples/nx works
               fine with its bogus font caching.

  Title:       EXAMPLES/NXTEXT ARTIFACTS
  Description: examples/nxtext.  Artifacts when the pop-up window is opened.
               There are some artifacts that appear in the upper left hand
               corner.  These seems to be related to window creation.  At
               tiny artifact would not be surprising (the initial window
               should like at (0,0) and be of size (1,1)), but sometimes
               the artifact is larger.
  Status:      Open
  Priority:    Medium.