RTEMS with post-boot code.

[Eric Norum]

You wrote:
>  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

I'm with Robin on this one.  Here are the problems I see with the  
jump-table-lookup way of handling things:

1) Where do you draw the line at what goes into the table?   The  
RTEMS entry points?  The libc entry points?  The networking entry  
points?  The libio entry points?

2) Everything gets pulled into the executable (since it is  
impossible to know a-priori which routines will be called).

3) There have to be two ways of calling every routine -- directly  
and through the jump-table unless you want to add the jump table  
lookup overhead to every program.

I find that the static-executable, coupled with a BOOTP PROM or BDM  
interface to load that executable, is completely convenient.

The argument now raised may be, ``but it would be so much quicker to  
test new code''.  My counter argument is that, ``RTEMS has no memory  
protection, so if your test code has a bug, in all likelihood you're  
going to trash some important part of RTEMS and have to reload  
anyhow -- or you'll probably *want* to reload RTEMS anyhow since  
you're never quite sure that your new code didn't tromp on something  
important''.  Even if all RTEMS is in ROM you still have to worry  
about the integrity of the associated data structures.

---
Eric Norum                                 eric at skatter.usask.ca
Saskatchewan Accelerator Laboratory        Phone: (306) 966-6308
University of Saskatchewan                 FAX:   (306) 966-6058
Saskatoon, Canada.