Update README, TODO, and make some unfinished configuration options dependent on EXPERIMENTAL

This commit is contained in:
Gregory Nutt 2014-09-13 15:45:26 -06:00
parent e6b3b9a40b
commit beb3238f36
3 changed files with 16 additions and 1 deletions

10
TODO
View File

@ -478,13 +478,23 @@ o Kernel/Protected Build
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.

View File

@ -227,6 +227,7 @@ config ARCH_STACK_DYNAMIC
bool "Dynamic stack"
default n if !BUILD_KERNEL || !LIBC_EXECFUNCS
default y if BUILD_KERNEL && LIBC_EXECFUNCS
depends on EXPERIMENTAL
---help---
Select this option if the user process stack resides in its own
address space. The naming of this selection implies that dynamic

View File

@ -3944,6 +3944,10 @@ Configurations
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
nsh:
This configuration directory provide the NuttShell (NSH). This is a
@ -4416,7 +4420,7 @@ Configurations
STATUS:
See the To-Do list below
(2014-8-30): Retesting today I am seeing a strange behavior: Serial
2014-8-30: Retesting today I am seeing a strange behavior: Serial
output is coming out in chunks with delays between the chunks. It
appears that something is not good in the serial port configuration.
I see no such chunky behavior in, for example, grahics output.