diff options
author | patacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3> | 2013-03-08 18:29:56 +0000 |
---|---|---|
committer | patacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3> | 2013-03-08 18:29:56 +0000 |
commit | 6137a8aa8f69cb0c197efced18d7e49144791666 (patch) | |
tree | fda5a4a9a19544410ab1c45ef4b3e83e92894241 /nuttx/TODO | |
parent | 62bccf6b7538cafa63e0ea91ccb603f58417a49a (diff) | |
download | px4-nuttx-6137a8aa8f69cb0c197efced18d7e49144791666.tar.gz px4-nuttx-6137a8aa8f69cb0c197efced18d7e49144791666.tar.bz2 px4-nuttx-6137a8aa8f69cb0c197efced18d7e49144791666.zip |
Move all memory manager globals to a structure. Pass structure pointer as a handler because MM APIs
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@5719 42af7a65-404d-4744-a932-0658087f49c3
Diffstat (limited to 'nuttx/TODO')
-rw-r--r-- | nuttx/TODO | 67 |
1 files changed, 62 insertions, 5 deletions
diff --git a/nuttx/TODO b/nuttx/TODO index 96a4f8c7e..5524fe256 100644 --- a/nuttx/TODO +++ b/nuttx/TODO @@ -1,4 +1,4 @@ -NuttX TODO List (Last updated March 6, 2013) +NuttX TODO List (Last updated March 8, 2013) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This file summarizes known NuttX bugs, limitations, inconsistencies with @@ -7,8 +7,8 @@ standards, things that could be improved, and ideas for enhancements. nuttx/ (10) Task/Scheduler (sched/) - (1) Memory Managment (mm/) - (3) Signals (sched/, arch/) + (2) Memory Managment (mm/) + (4) Signals (sched/, arch/) (2) pthreads (sched/) (2) C++ Support (6) Binary loaders (binfmt/) @@ -99,7 +99,7 @@ o Task/Scheduler (sched/) Status: Open. Priority: Medium Low. - Title: ON-DEMAND PAGE INCOMPLETE + 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. @@ -253,6 +253,53 @@ o Memory Managment (mm/) Priority: Medium/Low, a good feature to prevent memory leaks but would have negative impact on memory usage and code size. + Title: MEMORY MANAGEMENT IN THE KERNEL BUILD + Description: If the option CONFIG_NUTTX_KERNEL is selected, then NuttX will + built as two separate blobs: (1) a monolithic, NuttX kernel, + and (2) a user-space application blob. Communication between + the two is via traps in order to get from user-mode to kernel- + mode. + + At present, the final link of the kernel build fails because + of undefined memory allocation logic: kmm_initialize, kmm_addregion, + kmalloc, etc. In the flat build, these map to mm_initialize, + mm_addregion, malloc, etc. but they are undefined in the kernel + build. + + It has not been fully decided how to handle kernel- and user- + memory allocations. Here are some ideas: + + 1) Have only a single user-space heap and heap allocator that + is shared by both kernel- and user-modes. PROs: Simpler, + CONs: Awkward architecture and no security for kernel-mode + allocations. + + 2) Have two separate heap partitions and two copies of the + memory allocators. PROs: Not two difficult, CONs: Partitioning + the heap will not make the best use of heap memory. + + A complication is that the kernel needs to allocate both + protected, kernel private as well as user accessible memory + (such as for stacks). Perhaps this approach would require + three heap partitions. + + 3) Have a classes of two allocators: (1) one that allocates large + regions/pages of memory that can be protected or not, and + (2) the current memory allocator extended to support sbrk(). + The would still be kernel- and user-mode instances of the + memory allocators. Each would sbrk() as necessary to extend + their heap; the pages allocated for the kerne-mode allocator + would be protected but the pages allocated for the user-mode + allocator would not. PROs: Meets all of the needs. CONs: + would limit the size of allocations due to the physical + pages. Complex. There would likely be some small memory + inefficiencies due to quantization to pages. This really + feels like overkill for this class of processor. + + See other kernel build issues under "Build system" + Status: Open + Priority: Low, unless you need a working kernel build now. + o Signals (sched/, arch/) ^^^^^^^^^^^^^^^^^^^^^^^ @@ -281,6 +328,14 @@ o Signals (sched/, arch/) Status: Open Priority: Low. Even if there are only 31 usable signals, that is still a lot. + Title: USER-MODE SIGNALS + Description: In a kernel build (CONFIG_NUTTX_KERNEL). Signal handlers should + execute in user mode. This is to prevent a security hole where + user code can get control of the system in kernel mode if the signal + executes in kernel mode. + Status: Open + Priority: Low + o pthreads (sched/) ^^^^^^^^^^^^^^^^^ @@ -1054,6 +1109,8 @@ o Build system A similar issue exists in NSH that uses some internal OS interfaces that would not be available in a kernel build (such as foreach_task, foreach_mountpoint, etc.). + + See also "Memory Management" for another kernel build issue. Status: Open Priority: Low -- the kernel build configuration is not fully fielded yet. @@ -1772,7 +1829,7 @@ o z80/z8/ez80/z180 (arch/z80) Title: ZDS-II COMPILER PROBLEMS Description: The ZDS-II compiler (version 4.10.1) fails with an internal error - while compiler mm/mm_initialize. This has been reported as + 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 |