Lpc2000

At 12:13 AM 4/20/2006 +0000, jayasooriah wrote:
>* In the context of embedded systems, the OS (or kernel) assumes that
>the tasks are cooperative -- that they are making a kernel call not
>because they do not have the means to do this on their own.
>
>Just because a task can do anything it does not follow that having a
>task do whatever it can do without reference to other tasks (current
>and in the future) is a good idea.

Where on earth did you get the idea I thought otherwise?


Yet again, this has nothing to do with system/user mode.  It just describes 
a well designed library/kernal.  I agree, have always agreed, that a well 
designed kernal with behaving tasks is a good idea.

>For the above reason I do not find your argument relevant to the
>original proposition: to recognise that even in embedded systems, the
>notion of user vs system can be exploited to make the system easier to
>describe and manage.

You are arguing against a position I haven't taken.  A division of 
responsibilities is a good thing,  A random sprinkling of I/O and control 
code would, I agree, be a bad thing.  Limiting control to specific areas is 
just good design.

The question is: what extra advantage running in user mode and making calls 
to a system mode kernal provides over an application running in system mode 
making calls to a system mode kernal?

I see no advantage just from having two different modes w/o any distinction 
between them.

If you use SWI as the link mechanism,  you can in either case but it's a 
natural fit with the user/system case, then I see the following breakdown.

SWI advantages
         decouples the calling routines from the implementing 
routines.  This shows as an advantage in systems that have multiple 
applications loaded or have applications loaded into memory at runtime 
since they can share a common kernal implementation.

         Most natural implementations naturally provide the library as a 
single block of memory.  An advantage if you are loading multiple 
applications. perhaps but otherwise..?  Could be done straightforwardly 
enough with the linker if it was really desired, I've done a similar thing 
on a system with a fragmented memory map.

SWI disadvantages:
         decouples the calling routines from the implementing 
routines.  The normal type checking is broken across the SWI/IRQ 
barrier.  Presumably a well written implementation of the stub library on 
the caller side will substitute but it is still quite easy to change either 
the caller stub or the implementing routine independently and break the 
interface.  The same can happen with a linked library of course but you do 
have that extra level of type checking in the interface.

In either case a well designed application will usually segregate I/O 
functionality from processing functionality and base support routines will 
be separate again.  Much of the base support is reusable on multiple 
systems, some of the I/O functionality may be.

For a system with multiple applications I'd definitely consider SWI.  If I 
used SWI theres a good chance I'd run the app in user mode as it's a 
natural fit.  For a standard single application system though there is no 
advantage(1).

My original question was prompted by the suggestion that I thought I saw in 
tour post that user mode provided some significant protection.  If all it 
is turns out to be that it fits naturally with SWI that's fine.  I just 
don't see that being an advantage for your typical single application 
microcontroller embedded system.

(1) There is a single application type I thought of while writing this that 
would benefit from using SWI as a jump table.  That's the case where a 
single application runs on multiple HW platforms and relies on the HW 
platforms kernal to provide functionality that may be implemented 
differently on each one.  Not the type of application I was thinking of though.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/