--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/PDK/Source/GUID-2700AAC8-A034-5E7D-B0E0-26B49E68BB18.dita	Fri Jan 22 18:26:19 2010 +0000
@@ -0,0 +1,69 @@
+<?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 <xref href="GUID-5B1D8D9C-90EF-5FCC-8D7D-01B13D6C2E68.dita">Nanokernel</xref> 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_d0e366434_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