RTEMS with post-boot code.

[Jacob W Janovetz]

> What you refer to is called dynamic linking, and is available on operating
> systems similar in general design to RTEMS, such as vxWorks.
> 
> In this arrangement, you first boot the operating system, then load a
> program as one or more relocatable object modules. The kernel dynamically
> links them into the running executable (itself), performing all the relocation
> fixups that the ordinary linker normally does. To work, the kernel must keep
> its symbol table in memory, and add to it as new objects are loaded.
> 
> Such an arrangement is on the surface useful, and could presumeably be
> implemented in RTEMS, with a fair deal of work. There are some general
> problems, however:
> 
>     o what it you load the same module twice? Which one runs?
>     o how do you "unload" modules? They could be still running!
>     o precise version match between kernel and module is required,
>       but tricky to enforce
>     o etc
> 
> On the whole, having used vxWorks for many years, I find the RTEMS way of
> bundling the application with whatever parts of an OS it requires into a
> single executable unit is in many ways cleaner and easier. Maybe it's not
> so good for repeated compile/test/debug cycles, but it is much better for
> managing systems in the field. (It is also the traditional embedded systems
> approach).

Robin,

   I don't think I'm talking about something as elaborate as 
dynamic linking.  I don't need programs to share their libraries.
I just need a lookup-table for the OS routines.  Similar to what
DOS (Microsoft DOS) does with its built-in routines.  I know that,
because the size of DOS will change from version to version, there
exists a lookup table which give DOS applications a standard for
them to look to get addresses of _OS_ routines.

   I don't think it would involve much.  Just a _set_ place in
memory (maybe after a interrupt service table or something) that
can be guaranteed for every version of the OS build.  This table 
would consist of data statements:

   dc.l   &rtems_task_create
   dc.l   &rtems_task_destroy
   dc.l   &jakes_procedure
    .
    .
    .

   The order of these statments is critical.  Then, a library would
have to be created which looks like:

void jakes_procedure(int i)
{
   void (*func)(int i);
 
   func = (void *)(TableBaseAddress + JAKES_PROCEDURE_OFFSET);
   (*func)(i);
}


   Something like this, anyhow, is what I'd like.

   Cheers,
   Jake

-- 
   janovetz at uiuc.edu    | Once you have flown, you will walk the earth with
 University of Illinois | your eyes turned skyward, for there you have been,
                        | there you long to return.     -- da Vinci
        PP-ASEL         | http://www.cen.uiuc.edu/~janovetz/index.html