Newer
Older
NuttX TODO List (Last updated September 16, 2012)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This file summarizes known NuttX bugs, limitations, inconsistencies with
standards, things that could be improved, and ideas for enhancements.
(1) Memory Managment (mm/)
patacongo
committed
(2) pthreads (sched/)
(6) Binary loaders (binfmt/)
(17) Network (net/, drivers/net)
(4) USB (drivers/usbdev, drivers/usbhost)
patacongo
committed
(9) File system/Generic drivers (fs/, drivers/)
(5) Graphics subystem (graphics/)
patacongo
committed
(6) Build system / Toolchains
(5) Linux/Cywgin simulation (arch/sim)
patacongo
committed
(6) ARM (arch/arm/)
(2) ARM/i.MX (arch/arm/src/imx/)
(7) ARM/LPC214x (arch/arm/src/lpc214x/)
(0) ARM/LPC43x (arch/arm/src/lpc43xx/)
(3) ARM/LM3S6918 (arch/arm/src/lm3s/)
(1) Hitachi/Renesas SH-1 (arch/sh/src/sh1)
apps/
(5) Network Utilities (apps/netutils/)
(1) System libraries apps/system (apps/system)
(5) Other Applications & Tests (apps/examples/)
Title: CHILD PTHREAD TERMINATION
Description: When a tasks exits, shouldn't all of its child pthreads also be
terminated?
Status: Open
Priority: Medium, required for good emulation of process/pthread model.
Description: Implement sys/mman.h and functions
Status: Open
Priority: Low
Description: Implement sys/wait.h and functions. Consider implementing wait,
waitpid, waitid. At present, a parent has no information about
child tasks.
Update: A simple but usable version of waitpid() has been included.
This version is not compliant with all specifications and can be
enabled with CONFIG_SCHED_WAITPID.
Update: These are being fixed as they are encountered. There is
no accounting of how many interfaces have this problem.
Status: Open
Priority: Medium, required for standard compliance (but makes the
code bigger)
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.
Title: posix_spawn()
Description: This would be a good interface to add to NuttX. It is really
just a re-packaging of the existing, non-standard NuttX exec()
function.
Status: Open
Priority: Medium low.
o On-demand paging (sched/)
^^^^^^^^^^^^^^^^^^^^^^^^^
Title: ON-DEMAND PAGE 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.
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.
Status: Open
Priority: Low -- There is no plan to implement this.
Description: timer_getoverrun() (sched/timer_getoverrun.c) is not implemented.
Status: Open
Priority: Low -- There is no plan to implement this.
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.
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
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
Loading
Loading full blame...