RTEMS with post-boot code.

[Joel Sherrill]

On Wed, 29 Oct 1997, Eric Norum wrote:

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

This approach has not been used recently (AFAIK) with RTEMS.  The just
table is provided for RTEMS but I don't know that anyone uses it or that
it has been tested recently.  It is painful to use this apprach sometimes.
You still need RTEMS constants and you have to have a layer which maps
every call from C to the jump entry point format.

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

Well it is in the ROM.  If you have ROM space, this is not that bad a
disadvantage.  Especially if you avoid the jump table approach and just do
a link against the addresses in ROM.

> 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.

This is a problem.  A large maintenance problem more than likely because
this layer would vary form port to port.

> 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.

That is an issue.

I know of one project which utilized memory management to protect the
stacks from overflow.  They submitted the stack allocator extensions. I do
not think they ended protected the workspace although they did talk about
it.  You would have to have RTEMS at a different protection level than
application code to protect anything of use.  

But if I understand right, the original idea was just to put as much in
ROM as possible to minimize downloads.  If something gets trashed, a reset
will bring a stable copy out of ROM and then you can try to debug it
again.  I don't think the original intent was necessarily concerned with
being able to switch applicatins without an intervening reset -- although
I agree it would be a good feature.  I think it would personally distract
from my ability to debug.  Who would know for sure what dmage had been
done by a previous executable.  

--joel
Joel Sherrill                    Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985