dynamic loading tasks and address space

[Stanley Jobson]

hi till, hi all,

with till's help i managed to implement my rtems tasks as loadable modules.

first s.th. about the background:
 - basically my app consists of s.th. like a kernel and user land 
   tasks (rtems tasks)
 - these user land tasks are now implemented as "modules" which means
   they are compiled to separate object files, included into a tar file
   which is then linked to the image.
 - on system startup the kernel:
    - extracts the tar file to IMFS
    - loads the "modules"/tasks via cexp and
    - executes a defined entry point (init task, create rtems task, etc)
 - after having loaded and initialized these tasks work again as ordinary  
   rtems tasks.

so far so good. everything runs fine now and i am now able to load an
unload rtems task on runtime ;-)

now imagine we want to have two instances of the same task (source code).
therefore we need to create two rtems tasks, right? 

question: does each rtems task need its own, different, unique
entry_point? to get its own address space? how does rtems handle this?

imagine further that this tasks has two source files - one for the rtems
task entry_point and one for the application logic (or what else). 

question: what about this file? each instance of the task mentioned above
would need its own copy (especially of the global (static) variables),
right?

i cannot load this file twice cause this way i get name collisions with
global symbols (e.g. function names).
loading this file once is of course also problematic ...

in summary: on unix i can start two instances/processes of vim. vim
consists of several .c files linked to one object file. each object file is
loaded into its own address space and so theses two instances do not
conflict with eachother --> how to achieve this on rtems?


thx for listening and ur help!

regards,
stan