dynamic loading tasks and address space

[Till Straumann]

Stanley Jobson wrote:

>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? 
>  
>
yes

>question: does each rtems task need its own, different, unique
>entry_point?
>
no

> to get its own address space? how does rtems handle this?
>  
>
there is no separate address space. Rtems has no 'unix processes'. All 
tasks + the
kernel share a single, flat address space including memory, 
memory-mapped devices
etc.

>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?
>  
>
no. There is a single copy of the program text and all non-automatic 
variables.
Hence, if your code needs 'global' variables you must make it 
're-entrant' first.
E.g., by putting all globals into a 'struct', malloc'ing memory for that 
struct
at task initialization and passing a pointer to all routines that need 
to access the
global data. Instead of explicitely passing a pointer you can use RTEMS 
features
such as notepads or task variables [avoid task vars if possible - they 
add to
the context switching overhead] -- (RTM).

>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 ...
>  
>
not if the code is re-entrant. Note that RTEMS' C-library [newlibc] is 
reentrant already.
Every task (implicitely) has its own copy of libc globals such as 
'errno' 'stdin/stdout/stderr'
etc.

>in summary: on unix i can start two instances/processes of vim.
>
Think of a multithreaded application sharing a process' address space 
and resources;
that's how RTEMS [and many other RTOSes work].

> 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?
>  
>
See above.

HTH
-- Till

>
>thx for listening and ur help!
>
>regards,
>stan
>  
>