[RTEMS Project] #3835: Support statically allocated threads

[RTEMS trac]

#3835: Support statically allocated threads
-----------------------------+------------------------------
 Reporter:  Sebastian Huber  |       Owner:  Sebastian Huber
     Type:  enhancement      |      Status:  assigned
 Priority:  normal           |   Milestone:  5.1
Component:  score            |     Version:  5
 Severity:  normal           |  Resolution:
 Keywords:                   |  Blocked By:  3838
 Blocking:                   |
-----------------------------+------------------------------

Comment (by Sebastian Huber):

 Replying to [comment:8 Joel Sherrill]:
 > Replying to [comment:6 Sebastian Huber]:
 > > I would consider the FP context and the thread-local storage of a
 thread to be in the same access domain. These data areas should be private
 to a thread.
 >
 > I don't know if this was intended to respond to my concern with custom
 stack allocators or not. In the systems I know have used this, the memory
 is not available (mapped dynamically) or known statically (RTEMS runs in
 virtual address space).
 >
 > How does this work with custom stack allocators?

 The availability of statically initialized threads doesn't mean that
 everyone has to use them. They are optional. I also have no intention to
 remove the custom stack allocator. What changes is that the memory area
 allocated for the stack is used also to contain the thread-local storage
 and the FP context. These memory areas are private to a thread and non-
 executable. I really don't know what a potential problem could be with a
 custom allocator.

 I plan to statically initialize the stacks for the idle threads and the
 MPCI receive server thread. They will reside in special linker sections so
 that a BSP or application can control the placement in memory.

--
Ticket URL: <http://devel.rtems.org/ticket/3835#comment:9>
RTEMS Project <http://www.rtems.org/>
RTEMS Project