[ECOS] Re: Downloadable tasks?

[Richard Panton <rpanton@3glab.com>]

On Tue, 23 Jan 2001, Tony Armitstead wrote:

> Hi,
> 
> I am considering using eCos in a KS32C50100 (ARM) application which 
> requires down-loadable code images each of which contains 2 threads. My 
> ideas are:
> 
> 2. The eCos kernel would be extended to support a 'remote' kernel API 
> interface accessed via SWI 'calls'
> 
> 3. The downloaded images would be downloaded and their threads created 
> within eCos. Each image would have a table giving the location, stack ..... 
> of the threads within the image. Or maybe just an initialisation call which 
> would create the threads using the remote API interface. Each downloaded 
> image would be linked with a library of eCos API calls which just SWI down 
> to the resident eCos kernel.
> 
> So, does anyone have any thoughts on this - or maybe already done it (for ARM)!

I've been looking at similar enhancements. Some of the issues you may wish
to consider:

*	SWI handler needs to be enhanced to take and return arguments.

*	Do you need to support THUMB SWIs (have range of 0-255 maximum)?

	( I have a code fragment that can be used to support THUMB or ARM
          SWIs - you're welcome to take this )

*	What mode are the downloadable threads to run in: USER, SYSTEM or
SVC? Anything other than SVC mode requires changes to the context switch
code.

*	What level of protection is there to be between the downloadable
threads. This will be somewhere between none, and complete isolation.

*	You'll need to preallocate SWI numbers to specific functions. What
if a new kernel variant does not support some of these calls?

*	Are the downloadable images re-locateable, or do you have separate
binaries for the same process that can execute in (download space 0) and
(download space 1)?

*	On a similar note, will your eCos kernel pre-allocate memory for
each downloadable task, or will it use some sort of memory allocation to
partition the system at extension load-time?

*	What sort of protection from errant (i.e. buggy) or malicious
downloadable programs are you to have? Note that any thread can execute
the following code sequence to bring down the entire OS:
		
		mov	sp, #0		// Point to invalid stack
		stmfd	sp, {r0-lr}	// cause data fault

	The first action of the data fault routine is to attempt to
	preserve the registers on the (now invalid) stack, hence causing
	another data fault, etc. 

PS. Watch out for alarm functions.....

-- 
Richard Panton              Systems Architect          3G Lab Ltd.
richard.panton@3glab.com    http://www.3glab.org/