From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Panton To: Tony Armitstead Cc: ecos-discuss@sourceware.cygnus.com Subject: [ECOS] Re: Downloadable tasks? Date: Wed, 24 Jan 2001 08:12:00 -0000 Message-id: References: <5.0.2.1.0.20010123160652.00a66090@mail.noral.co.uk> X-SW-Source: 2001-01/msg00402.html 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/