luchianmihai/walnux
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Fix a typo that crept into lpc17_allocateheap.c in the recent kernel allocator changes

Browse source 
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@5729 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
patacongo 2013-03-11 13:21:33 +00:00
parent 3781d761f3
commit 2b64d4742a
8 changed files with 74 additions and 63 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

57
TODO
View file

@ -254,47 +254,38 @@ o Memory Managment (mm/)
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:
Description: At present, there are two options for memory management in
the NuttX kernel build:
1) Have only a single user-space heap and heap allocator that
is shared by both kernel- and user-modes. PROs: Simpler,
is shared by both kernel- and user-modes. PROs: Simple,
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
2) Two separate heap partitions and two copies of the memory
allocators. One heap partition is protected and the the
is user accessible. PROs: Still simple, 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.
A complication is that the kernel needs to allocate both
protected, kernel private as well as user accessible memory
(such as for stacks). A more traditional approarch would be
something like:
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.
3) Implement 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 kernel-mode allocator would be protected but the pages
allocated for the user-mode allocator would not. PROs:
Meets all of the needs. CONs: Complex. Memory losses,
due to quanitization. sbrk'ed memory would not be
contiguous; this would limit the sizes of allocations
due to the physical pages.
This feels like overkill for this class of processor.
This approach probably could not be implemented using
a simple memory protection unit (such as that of the
ARM Cortex-M family).
See other kernel build issues under "Build system"
Status: Open

2
arch/arm/src/lpc17xx/lpc17_allocateheap.c
View file

@ -43,7 +43,7 @@
#include <debug.h>
#include <nuttx/arch.h>
#include <nuttx/mm.h>
#include <nuttx/kmalloc.h>
#include <arch/board/board.h>
#include "chip.h"

15
arch/z16/src/common/up_initialize.c
View file

@ -1,5 +1,5 @@
/****************************************************************************
* common/up_initialize.c
* arch/z16/src/common/up_initialize.c
*
* Copyright (C) 2008-2009, 2011-2013 Gregory Nutt. All rights reserved.
* Author: Gregory Nutt <gnutt@nuttx.org>
@ -43,24 +43,17 @@
#include <nuttx/arch.h>
#include <nuttx/fs/fs.h>
#include <nuttx/mm.h>
#include <nuttx/ramlog.h>
#include <arch/board/board.h>
#include "up_arch.h"
#include "up_internal.h"
/****************************************************************************
* Definitions
****************************************************************************/
/* Define to enable timing loop calibration. CONFIG_DEBUG and
* CONFIG_ARCH_LOWPUTC must also be enabled in the .config file because
* the logic uses lldbg()
*/
#undef CONFIG_ARCH_CALIBRATION
/****************************************************************************
* Public Data
****************************************************************************/
@ -94,7 +87,7 @@ volatile FAR chipreg_t *current_regs;
*
****************************************************************************/
#if defined(CONFIG_ARCH_CALIBRATION) && defined(CONFIG_DEBUG) && defined(CONFIG_ARCH_LOWPUTC)
#if defined(CONFIG_ARCH_CALIBRATION) && defined(CONFIG_DEBUG)
static void up_calibratedelay(void)
{
int i;
@ -140,7 +133,7 @@ void up_initialize(void)
up_calibratedelay();
/* Add extra memory fragments to the memory manager */
/* Add any extra memory fragments to the memory manager */
#if CONFIG_MM_REGIONS > 1
up_addregion();

21
arch/z80/src/common/up_initialize.c
View file

@ -43,32 +43,21 @@
#include <nuttx/arch.h>
#include <nuttx/fs/fs.h>
#include <nuttx/mm.h>
#include <arch/board/board.h>
#include "chip/switch.h"
#include "up_arch.h"
#include "up_internal.h"
/****************************************************************************
* Definitions
****************************************************************************/
/* Define to enable timing loop calibration */
#undef CONFIG_ARCH_CALIBRATION
/****************************************************************************
* Public Data
* Pre-processor Definitions
****************************************************************************/
/****************************************************************************
* Private Types
****************************************************************************/
/****************************************************************************
* Private Data
****************************************************************************/
/****************************************************************************
* Private Functions
****************************************************************************/
@ -83,7 +72,7 @@
*
****************************************************************************/
#if defined(CONFIG_ARCH_CALIBRATION) & defined(CONFIG_DEBUG)
#if defined(CONFIG_ARCH_CALIBRATION) && defined(CONFIG_DEBUG)
static void up_calibratedelay(void)
{
int i;
@ -129,7 +118,7 @@ void up_initialize(void)
up_calibratedelay();
/* Add extra memory fragments to the memory manager */
/* Add any extra memory fragments to the memory manager */
#if CONFIG_MM_REGIONS > 1
up_addregion();

2
include/nuttx/kmalloc.h
View file

@ -113,7 +113,7 @@ extern "C"
/* This familiy of allocators is used to manage kernel protected memory */
#ifndef CONFIG_NUTTX_KERNEL
#if !defined(CONFIG_NUTTX_KERNEL)
/* If this is not a kernel build, then these map to the same interfaces
* as were used for the user-mode function.
*/

10
include/nuttx/sched.h
View file

@ -383,10 +383,18 @@ struct task_group_s
#endif
/* FILE streams ***************************************************************/
/* In a flat, single-heap build. The stream list is allocated with this
* structure. But kernel mode with a kernel allocator, it must be separately
* allocated using a user-space allocator.
*/
#if CONFIG_NFILE_STREAMS > 0
#if defined(CONFIG_NUTTX_KERNEL) && defined(CONFIG_MM_KERNEL_HEAP)
FAR struct streamlist *tg_streamlist;
#else
struct streamlist tg_streamlist; /* Holds C buffered I/O info */
#endif /* CONFIG_NFILE_STREAMS */
#endif
#endif
/* Sockets ********************************************************************/

19
sched/group_create.c
View file

@ -189,6 +189,25 @@ int group_allocate(FAR struct task_tcb_s *tcb)
return -ENOMEM;
}
#if CONFIG_NFILE_STREAMS > 0 && defined(CONFIG_NUTTX_KERNEL) && \
defined(CONFIG_MM_KERNEL_HEAP)
/* In a flat, single-heap build. The stream list is allocated with the
* group structure. But in a kernel build with a kernel allocator, it
* must be separately allocated using a user-space allocator.
*/
group->tg_streamlist = (FAR struct streamlist *)
kuzalloc(sizeof(struct streamlist));
if (!group->tg_streamlist)
{
kfree(group);
return -ENOMEM;
}
#endif
/* Attach the group to the TCB */
tcb->cmn.group = group;

11
sched/group_leave.c
View file

@ -218,6 +218,17 @@ static inline void group_release(FAR struct task_group_s *group)
}
#endif
#if CONFIG_NFILE_STREAMS > 0 && defined(CONFIG_NUTTX_KERNEL) && \
defined(CONFIG_MM_KERNEL_HEAP)
/* In a flat, single-heap build. The stream list is part of the
* group structure. But in a kernel build with a kernel allocator, it
* must be separately de-allocated user the user-space deallocator.
*/
sched_ufree(group->tg_streamlist);
#endif
/* Release the group container itself */
sched_kfree(group);