sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update TODO and a README

Browse Source
This commit is contained in:
Gregory Nutt 2014-09-16 13:58:55 -06:00
parent 4bbaf80cab
commit 62a11fde1d
2 changed files with 6 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
TODO
View File

@ -1,4 +1,4 @@
NuttX TODO List (Last updated September 13, 2014)
NuttX TODO List (Last updated September 16, 2014)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This file summarizes known NuttX bugs, limitations, inconsistencies with
@ -12,7 +12,7 @@ nuttx/
(2) Memory Managment (mm/)
(3) Signals (sched/, arch/)
(2) pthreads (sched/)
(9) Kernel/Protected Builds
(8) Kernel/Protected Builds
(4) C++ Support
(6) Binary loaders (binfmt/)
(13) Network (net/, drivers/net)
@ -471,34 +471,6 @@ o Kernel/Protected Build
improvement. However, there is no strong motivation now do
do that partitioning work.
Title: ARMVv7-A STACK ISSUE
Description: Currently a program running as a process in the kernel build mode
cannot run other programs that reside on the file system. Why?
Because in order to run those other programs, the new program's
address environment must be instantiated in memory to load the
.text and .data and to allocate the initial user space components
from the new user heap.
However, the previous program's stack currently resides in its
heap. So when a process tries to run another program, its heap
is unmapped and the system crashes.
The fix is to add a separate stack in a separate memory region
that does not get unmapped when creating new processes. There
are hooks in place to do this; I just need to get time to get
that done.
UPDATE: I don't think it is that simple. Startup logic will need
to access the new stack in its correct location to do things like
setup task arguments. So I don't think that there is anyway to
do that without losing the current stack.
I may have to do the Linux solution: Two stacks for each thread:
The main user stack, and a tiny kernel mode stack.
Status: Open
Priority: Pretty high... the kernel build is useless without this
capability.
o C++ Support
^^^^^^^^^^^

21
configs/sama5d4-ek/README.txt
View File

@ -3930,23 +3930,10 @@ Configurations
file system. A considerable amount of testing has been done and
there are no known defects as of this writing.
2014-9-13: Currently a program running as a process in the kernel build
mode cannot run other programs that reside on the file system. Why?
Because in order to run those other programs, the new program's
address environment must be instantiated in memory to load the .text
and .data and to allocate the initial user space components from the
new user heap.
However, the previous program's stack currently resides in its heap.
So when a process tries to run another program, its heap is unmapped
and the system crashes. The fix is to add a separate stack in a
separate memory region that does not get unmapped when creating new
processes. There are hooks in place to do this; I just need to get
time to get that done.
To see the bug in action:
nsh> /bin/hello
2014-9-16: After some substantial effort, I think I may have resolved
the last of the mainstream bugs that prevented from executing other
user processes from a user processes. Long story but I am glad to
haave that done.
nsh: