Re: [ECOS] Re: Downloadable tasks?

[Tony Armitstead <tonya@noral.com>]

Thanks for the comments Richard. See my own comments below:

At 04:12 PM 1/24/01 +0000, Richard Panton wrote:
>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.

Does eCos use SWI itself? I tried to follow this through and got to 
__handle_exception. I reckon I need to get in there before this so that I 
can decode the SWI immediate parameter.

>*       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 )

I do not use thumb code at all. (Is that thumbs up or down!)

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

SVC is fine.

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

None. ARM7 has no MMU and no process protection mechanism.

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

Good point for a generic implementation. However I am probably going to be 
'well matched' between the resident kernel and the downloaded images so I 
dont think this will upset me.

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

My thoughts are that they will be linked images but not located. We can 
then locate the image during the download process. There will be a resident 
thread which the host communicates with. This thread can allocate the 
required memory for an image and then the located image can be placed into 
memory and initialised etc...

A completely different approach is available to us here. We will always 
know the set of images required in the system - but the image set is 
configurable by the user. So we could link/locate eCos with the images and 
then send down a single image containing the complete application. However 
this needs our interface software to invoke a linker to build this final 
image. We would then need this linker/locater to run on several host 
platforms (Win32  + unix + Solaris .....).

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

Well we (specifically me) will be writing the images and if I write buggy 
or malicious code I will severely reprimand myself!

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

What is the issue here? Only thing I could think of is a 'pointer to a 
function' issue but since the ARM7 is a simple non MMU core I don't see a 
problem. What am I missing?

Many thanks for your input.


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


/======================================================\
| Tony Armitstead BSc        EMail: tonya@noral.com    |
| Development Manager        Phone: +44 (0)1254 295807 |
| Noral Micrologics            Fax: +44 (0)1254 295801 |
| WEB: http://www.noral.com   FTP: ftp://ftp.noral.com |
\======================================================/