--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Adaptation/GUID-2700AAC8-A034-5E7D-B0E0-26B49E68BB18.dita	Fri Oct 15 14:32:18 2010 +0100
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License 
+"Eclipse Public License v1.0" which accompanies this distribution, 
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+    Nokia Corporation - initial contribution.
+Contributors: 
+-->
+<!DOCTYPE concept
+  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-2700AAC8-A034-5E7D-B0E0-26B49E68BB18" xml:lang="en"><title>Personality Layer for Real Time Applications</title><shortdesc>A base port can add a software layer called a personality
+layer to the Kernel to provide an emulation of a real time operating
+system (RTOS)</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>. You can provide a personality layer so that a phone can run existing
+protocol stacks, for example, mobile telephony signalling stacks,
+or Bluetooth stacks, on the same CPU that runs the Symbian platform
+applications. </p>
+<p>Such protocol stacks, often referred to as Real Time Applications
+(RTA), almost always run on an RTOS, and the aim of the personality
+layer is to provide the same API as the RTOS, or at least as much
+of it as is required by the RTA. The RTA can then run, using the Kernel
+Architecture 2 Nanokernel layer as the underlying real time kernel. </p>
+<p>The following diagram illustrates the point simply. </p>
+<fig id="GUID-AA5502A3-37BE-5A73-A8D9-1B18DDCC8C96">
+<image href="GUID-058FAE44-DF72-53E2-BE62-EDC840A7C87F_d0e25110_href.png" placement="inline"/>
+</fig>
+<p>There is sample code at <filepath>...\e32\personality\...</filepath> that you should refer to while reading this. </p>
+<section id="GUID-D1217729-E0E4-5A02-A02F-524EA9F1D679"><title>RTOS
+environment features</title> <p>As a basis for emulating an RTOS,
+the RTOS is assumed to provide the following features: </p> <ul>
+<li id="GUID-107CEB20-80DA-5AF8-A116-C5FA5E437993"><p>Threads </p> </li>
+<li id="GUID-496701DC-E711-5509-B593-5B5A51A7DFC2"><p>Thread synchronisation/communication </p> </li>
+<li id="GUID-5ADDB09E-7528-50E0-8661-C64C91AF32CA"><p>Thread scheduling
+following a hardware interrupt </p> </li>
+<li id="GUID-4856FE5E-95E6-5455-B226-9314071F948E"><p>Timer management
+functionality </p> </li>
+<li id="GUID-C721F13B-14F9-5E01-9721-19E9475A421B"><p>Memory management. </p> </li>
+</ul> <p><b>Threads</b> </p> <p>Threads are independent units of execution,
+usually scheduled on a strict highest-priority-first basis. There
+are generally a fixed number of priorities. Round robin scheduling
+of equal priority threads may be available but is usually not used
+in real time applications. Dynamic creation and destruction of threads
+may or may not be possible. </p> <p><b>Thread synchronisation/communication</b> </p> <p>Typical examples
+of such thread synchronisation and communication mechanisms are semaphores,
+message queues and event flags. </p> <p>There is wide variation between
+systems as to which primitives are provided and what features they
+support. Again, dynamic creation and destruction of such synchronisation
+and communication objects may or may not be supported. Mutual exclusion
+protection is often achieved by simply disabling interrupts, or occasionally
+by disabling rescheduling. </p> <p><b>Thread scheduling following a hardware interrupt</b> </p> <p>This
+is usually achieved by allowing interrupt service routines (ISRs)
+to make system calls which perform operations such as signalling a
+semaphore, posting a message to a queue or setting event flags, which
+would cause a thread waiting on the semaphore, message queue or event
+flag to run. </p> <p>Some systems don't allow ISRs to perform these
+operations directly but require them to queue some kind of deferred
+function call. This is a function which runs at a lower priority than
+hardware interrupts (i.e. with interrupts enabled) but at a higher
+priority than any thread - for example a Nucleus Plus HISR. The deferred
+function call then performs the operation which causes thread rescheduling. </p> <p><b>Timer management functionality</b> </p> <p>A timer management
+function is usually also provided, allowing several software timers
+to be driven from a single hardware timer. On expiry, a software timer
+may call a supplied timer handler, post a message to a queue or set
+an event flag. </p> <p><b>Memory management</b> </p> <p>An RTOS often provides memory management,
+usually in the form of fixed size block management as that allows
+real time allocation and deallocation. Some RTOSs may also support
+full variable size block management. However most RTOSs do not support
+use of a hardware MMU and, even if the RTOS supports it (for example
+OSE does), the real time applications under consideration do not make
+use of such support since they are generally written to run on hardware
+without an MMU. </p> </section>
+</conbody></concept>
\ No newline at end of file