This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Downloadable tasks?
- To: Tony Armitstead <tonya at noral dot com>
- Subject: [ECOS] Re: Downloadable tasks?
- From: Richard Panton <rpanton at 3glab dot com>
- Date: Wed, 24 Jan 2001 16:12:58 +0000 (GMT)
- cc: ecos-discuss at sourceware dot cygnus dot 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/