Skip to content
TODO 98.6 KiB
Newer Older
NuttX TODO List (Last updated March 6, 2013)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
patacongo's avatar
patacongo committed

This file summarizes known NuttX bugs, limitations, inconsistencies with 
standards, things that could be improved, and ideas for enhancements.

 (10)  Task/Scheduler (sched/)
  (2)  C++ Support
 (16)  Network (net/, drivers/net)
  (4)  USB (drivers/usbdev, drivers/usbhost)
 (11)  Libraries (libc/, )
  (9)  File system/Generic drivers (fs/, drivers/)
  (1)  Pascal add-on (pcode/)
patacongo's avatar
patacongo committed
  (1)  Documentation (Documentation/)
  (7)  Build system / Toolchains
  (5)  Linux/Cywgin simulation (arch/sim)
patacongo's avatar
patacongo committed
  (1)  ARM/C5471 (arch/arm/src/c5471/)
patacongo's avatar
patacongo committed
  (3)  ARM/DM320 (arch/arm/src/dm320/)
  (2)  ARM/i.MX (arch/arm/src/imx/)
patacongo's avatar
patacongo committed
  (3)  ARM/LPC17xx (arch/arm/src/lpc17xx/)
  (7)  ARM/LPC214x (arch/arm/src/lpc214x/)
patacongo's avatar
patacongo committed
  (2)  ARM/LPC313x (arch/arm/src/lpc313x/)
  (0)  ARM/LPC43x (arch/arm/src/lpc43xx/)
patacongo's avatar
patacongo committed
  (3)  ARM/STR71x (arch/arm/src/str71x/)
  (6)  ARM/STM32 (arch/arm/src/stm32/)
  (3)  AVR (arch/avr)
patacongo's avatar
patacongo committed
  (0)  Intel x86 (arch/x86)
  (5)  8051 / MCS51 (arch/8051/)
patacongo's avatar
patacongo committed
  (3)  MIPS/PIC32 (arch/mips)
  (1)  Hitachi/Renesas SH-1 (arch/sh/src/sh1)
patacongo's avatar
patacongo committed
  (4)  Renesas M16C/26 (arch/sh/src/m16c)
 (11)  z80/z8/ez80/z180 (arch/z80/)
patacongo's avatar
patacongo committed
  (1)  mc68hc1x (arch/hc)
patacongo's avatar
patacongo committed

apps/

  (5)  Network Utilities (apps/netutils/)
  (1)  System libraries apps/system (apps/system)
  (5)  Other Applications & Tests (apps/examples/)
patacongo's avatar
patacongo committed
o Task/Scheduler (sched/)
  ^^^^^^^^^^^^^^^^^^^^^^^

  Title:       CHILD PTHREAD TERMINATION
patacongo's avatar
patacongo committed
  Description: When a tasks exits, shouldn't all of its child pthreads also be
               terminated?
patacongo's avatar
patacongo committed
  Status:      Closed.  No, this behavior will not be implemented.
patacongo's avatar
patacongo committed
  Priority:    Medium, required for good emulation of process/pthread model.

patacongo's avatar
patacongo committed
  Title:       TICKLESS OS
  Description: On a side note, I have thought about a tick-less timer for the OS
               for a long time.  Basically we could replace the periodic system
               timer interrupt with a one-shot interval timer programmed for the
               next interesting event time.  That is one way to both reduce the
               timer interrupt overhead and also to increase the accuracy of
               delays.

               Current timer processing is in sched/sched_processtimer.c:

               1) Calls clock_timer() which just increments a counter (the system
                  timer -- basically "up-time"). This is only used when code asks
                  for the current time.  In a tickless OS, some substitute answer
                  for the question "What time is it?" would need to be developed.
                  You could use an RTC? Or maybe logic that gets the time until the
                  next interval expiration and computes the current time. The
                  solution is not too difficult, but depends on a hardware solution.

               2) Calls wd_timer() which handles the link list of ordered events:
                  Each timer event is saved with the delta time to the next event
                  in the list. So an interval timer would be perfect to implement this.

               3) sched_process_timeslice(). Then there is round-robin time-slicing.

patacongo's avatar
patacongo committed
               The primary advantage of a tickless OS is that is would allow for
               reduce power consumptions.  That is because timer interrupts will
               usually awaken CPUs from reduced power consumption states.
  Status:      Open.  There will probably be no tickless OS implementation unless
               someone gets motivated and drives the change.
patacongo's avatar
patacongo committed
  Priority:    Low

patacongo's avatar
patacongo committed
  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 PAGE INCOMPLETE
  Description: On-demand paging has recently been incorporated into the RTOS.
               The design of this feature is described here:
patacongo's avatar
patacongo committed
               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.
patacongo's avatar
patacongo committed
  Status:      Open.  This has been put on the shelf for some time.
  Priority:    Medium-Low

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

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

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

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

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

  Title:       ISSUES WITH atexit() AND on_exit()
  Description: These functions execute with the following bad properties:
  
               1. They run with interrupts disabled,
               2. They run in supervisor mode (if applicable), and
               3. They do not obey any setup of PIC or address
                  environments. Do they need to?

               The fix for all of these issues it to have the callbacks
               run on the caller's thread (as with signal handlers).
  Status:      Open
  Priority:    Medium Low.  This is an important change to some less
               important interfaces.  For the average user, these
               functions are just fine the way they are.

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

               The same tasking arrangement is used by the standard function
               posix_spawn().  However, posix_spawn uses the non-standard, internal
               NuttX interface task_reparent() to replace the childs parent task
               with the caller of posix_spawn().  That cannot be done with vfork()
               because we don't know what vfork() is going to do.
               Any solution to this is either very difficult or impossible without
               an MMU.
  Status:      Open
  Priority:    Low (it might as well be low since it isn't going to be fixed).

  Title:       errno IS NOT SHARED AMONG THREADS
  Description: In NuttX, the errno value is unique for each thread.  But for
               bug-for-bug compatibility, the same errno should be shared by
               the task and each thread that it creates.  It is *very* easy
               to make this change:  Just move the pterrno field from
patacongo's avatar
patacongo committed
               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).
patacongo's avatar
patacongo committed
o Memory Managment (mm/)
  ^^^^^^^^^^^^^^^^^^^^^^

  Title:       FREE MEMORY ON TASK EXIT
patacongo's avatar
patacongo committed
  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
Loading
Loading full blame...