rbheap memory protection

Hesham Moustafa heshamelmatary at gmail.com
Wed May 9 15:03:15 UTC 2012

I had reviewed rbheap code and i have some comments

   - first

rtems_status_code rtems_rbheap_initialize(
  rtems_rbheap_control *control,
  void *area_begin,
  uintptr_t area_size,
  uintptr_t alignment,
  rtems_rbheap_extend_descriptors extend_descriptors,
  void *handler_arg

this function initialize just one area of memory to be manipulated by
rbheap manager , and it behaves like rtems_partition_create( ) and
rtems_region_create. I am thinking the initializing function initialize
rtems_rbheap_control with a MAXIMUM rnheap control
struct number to support more than one rbheap managed memory area.

   - Second

 * The red-black tree heap provides a memory allocator suitable to implement
 * the malloc() and free() interface.  It uses a first-fit allocation
 * In the red-black tree heap the administration data structures are not
 * contained in the managed memory area.  Thus writing beyond the
boundaries of
 * a chunk does not damage the data to maintain the heap.  This can be used
 * example in a task stack allocator which protects the task stacks from
 * by other tasks.  The allocated and free memory parts of the managed area
 * called chunks.  Each chunk needs a descriptor which is stored outside of
 * managed area.

 The comment (which is in the rbheap.h file )indicated that we can use
rbheap as a task stack allocator and protect each  task stacks from
access by other tasks. I guessed that memory protection attributes would
exist in rtems_rbheap_chunk struct ,
but i did not found anything related to memory protection so far. So my
question how rbheap could be used to allocate stacks for tasks that one
task can not corrupt other task stack ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20120509/f9075d28/attachment-0001.html>

More information about the devel mailing list