This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Re: Downloadable tasks?
- To: Richard Panton <rpanton at 3glab dot com>
- Subject: Re: [ECOS] Re: Downloadable tasks?
- From: Tony Armitstead <tonya at noral dot com>
- Date: Thu, 25 Jan 2001 15:25:36 +0000
- Cc: ecos-discuss at sourceware dot cygnus dot com
- References: <5.0.2.1.0.20010123160652.00a66090@mail.noral.co.uk>
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 |
\======================================================/