<?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-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF" xml:lang="en"><title>Important+
−
Changes between EKA1 and Kernel Architecture 2</title><shortdesc/><prolog><metadata><keywords/></metadata></prolog><conbody>+
−
<p>This document is a summary of the important changes made between EKA2 and+
−
the Kernel Architecture 2. </p>+
−
<ul>+
−
<li id="GUID-39A4F67F-15DD-5443-AF04-B51E659AD158"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-1F882F2F-3BF4-5891-824D-01144652A771">Real time kernel</xref>  </p> </li>+
−
<li id="GUID-703989BD-22DD-5B48-BD44-03A6BCDE4B96"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-93FC5632-139C-529C-81BF-723D2931E422">Multi-threaded kernel</xref>  </p> </li>+
−
<li id="GUID-B8B0160F-9762-5CB2-BB0E-F363E89F6DB5"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-58061C31-3D55-5C92-86A6-9A07748DE12D">Memory model</xref>  </p> </li>+
−
<li id="GUID-E5C26246-2536-5092-B241-49BC0D7639F4"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-AEB5D074-7993-5ECE-8168-FFD7C7119842">Bootstrap</xref>  </p> </li>+
−
<li id="GUID-77CB12E7-B1AA-5B94-AACE-E616289BAC09"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-858E4DFA-3988-566B-9B9C-614D7D64843D">Chunks per process</xref>  </p> </li>+
−
<li id="GUID-45E655B9-11E5-5790-AA7D-BEA5A57ADC44"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-4F31E633-3418-5FEF-B034-E4E42D12ECAE">Releasing blocked threads</xref>  </p> </li>+
−
<li id="GUID-8DC829A6-ECF3-5DA6-A212-C47242B7CF2E"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-86BE8113-3442-585D-8AA1-622C6A0E5C33">Stricter checking on the use of invalid handles</xref>  </p> </li>+
−
<li id="GUID-21898C1A-9AF1-5A6A-B151-2446D8B26210"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-70A788E3-EDB4-52B5-85F1-083F0C041161">Kernel is no longer dependent on EUSER.DLL</xref>  </p> </li>+
−
<li id="GUID-1915EE78-FBCC-5B1A-BA16-84FF781331D1"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-14A08FAE-ADA1-55A8-9398-309E7FE517E3">Kernel-side code no longer leaves</xref>  </p> </li>+
−
<li id="GUID-7372DD68-A1E0-552B-B83E-6469586F4369"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-BCDC2615-0F4A-55A2-8806-0963C2939349">No kernel-Side support for unicode</xref>  </p> </li>+
−
<li id="GUID-9D2D33C4-B3E1-5169-B10C-229318C69D9F"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-AA9A48C6-5033-5459-AC1A-809FAEFB9001">Kernel-side code uses DBase instead of CBase</xref>  </p> </li>+
−
<li id="GUID-080AD2D2-2394-5653-89E8-3ADA0FB9AA38"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-745A19A0-FA97-5250-B493-C0613EAE162E">Asynchronous deletion</xref>  </p> </li>+
−
<li id="GUID-125A5C43-0D8C-5CEB-99F0-2FBF80C466FD"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-EBD2C3D9-D422-5EDC-B2DF-BEBE713DFF49">Accessing user side memory directly not permitted</xref>  </p> </li>+
−
<li id="GUID-42EA847A-CC94-5630-BC52-FF2A33DD0D39"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-E0313A56-3F85-5614-964A-30972BA0193D">Kernel side code uses DObject instead of CObject</xref>  </p> </li>+
−
<li id="GUID-B16C285F-58CF-543A-91DA-42E12738D70F"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-FADA0E2F-A37B-58A1-93AD-5DEF04ECD0D1">Device Driver Model</xref>  </p> </li>+
−
<li id="GUID-4E25E221-01D6-5F68-A205-2D03EF837DC4"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-66C87C5D-D71B-5D98-9B49-C7FD4D18D540">Base porting</xref>  </p> </li>+
−
<li id="GUID-B02F4ACE-2139-588B-AEF4-14773B16EDF3"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-FA2341A0-1743-5FE3-9C22-E2575816BE8D">Emulator</xref>  </p> </li>+
−
<li id="GUID-35FE60FE-0C63-5CC1-BC50-85B050265ADB"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-B3073835-E9D7-5219-BC63-D7296ABB9B5C">Kernel-side messages</xref>  </p> </li>+
−
<li id="GUID-8C1A6D8D-23C7-5A80-A915-0938FC129F28"><p> <xref href="GUID-AD2BD987-E097-5E1F-A914-B91CFB706D51.dita">Environment+
−
Slots</xref>  </p> </li>+
−
<li id="GUID-A125477D-24BD-5C59-96FA-52C8448A8286"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-8D788A9A-3AE1-5A5E-9761-5DCC81A60603">Power management</xref>  </p> </li>+
−
<li id="GUID-6A2B9214-A194-5819-A0FA-EC7B6E060563"><p> <xref href="GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF.dita#GUID-43BC99CA-9D60-557C-A43C-99EF1D6E4ECF/GUID-E8321E95-FEE1-516D-8EED-30B6C2C25E18">Support for alternative heap allocators</xref>  </p> </li>+
−
</ul>+
−
<section id="GUID-1F882F2F-3BF4-5891-824D-01144652A771"><title>Real time kernel</title> <p>One+
−
of the main design goals for EKA2 is to provide real-time guarantees for a+
−
subset of kernel operations. Real time performance is one that guarantees+
−
a response time; it does not mean that the response time is necessarily fast,+
−
it means that the time taken is bounded, i.e. it is deterministic or predictable. </p> <p>Very+
−
few changes to user side code are needed; the aim has been to maintain compatibility+
−
at the EUSER level as far as possible. Device drivers, however, will need+
−
some changes at the EUSER level, and more so on the kernel side. See the <xref href="GUID-0437DB4C-FC4E-51DC-BB4C-95C0B26834F5.dita">Device Driver Guide</xref> for+
−
details. </p> </section>+
−
<section id="GUID-93FC5632-139C-529C-81BF-723D2931E422"><title> Multi-threaded+
−
kernel</title> <p>In EKA2, the kernel is multi-threaded, i.e. any number of+
−
threads can now run on the kernel side. This means that a lower priority kernel+
−
thread can be preempted by a higher priority thread. </p> <p>Each user thread+
−
has two stacks: a user stack as in EKA1, and an additional kernel stack allowing+
−
it to be preempted virtually anywhere while executing kernel-side code. This+
−
adds approximately 4k to each thread's memory requirements. </p> <p>This change+
−
has the effect of simplifying device driver design. It also means that most+
−
kernel-side data structures need to be protected against concurrent accesses+
−
to prevent race conditions. Several synchronisation primitives are available+
−
to achieve this. </p> <p>A deadlock prevention strategy must be followed by+
−
kernel-side code. </p> </section>+
−
<section id="GUID-58061C31-3D55-5C92-86A6-9A07748DE12D"><title>Memory model</title> <p>The+
−
EKA2 core kernel is MMU-agnostic. All MMU code is isolated into a “memory+
−
model”, which is linked at build time against the kernel. EKA2 provides three+
−
different memory models: </p> <ul>+
−
<li id="GUID-59368906-3EC3-52CF-A1B9-239ABAEB7F21"><p>Moving memory model:+
−
This is functionally equivalent to EKA1, and is intended for ARMv4 and ARMv5+
−
CPUs. A single page directory is used and page directory entries are moved+
−
between the home and run sections at address space switch time. </p> </li>+
−
<li id="GUID-D4FCDAB7-0D20-5122-86CC-CAAA5F551DF7"><p>Multiple memory model:+
−
This is a new model for CPUs based on ARMv6 architecture. There is one page+
−
directory per process </p> </li>+
−
<li id="GUID-BE4852CB-3C4C-59A0-807D-D8E6150635EB"><p>Single memory model:+
−
This model can be used for CPUs that have no MMU, or to simplify of porting+
−
the core kernel to a new MMU-aware CPU. In the latter case, the MMU is enabled+
−
but there is a single address space in the system. This allows incremental+
−
porting to a new CPU, by first porting the kernel and then the MMU. </p> </li>+
−
</ul> <p>The memory map (e.g. the base address of the ROM image) has changed.+
−
Therefore any code relying on the EKA1 memory map will need changing. The+
−
impact should be minimal, as code outside the kernel should not be making+
−
assumptions about memory layout. </p> </section>+
−
<section id="GUID-AEB5D074-7993-5ECE-8168-FFD7C7119842"><title>Bootstrap</title> <p>The+
−
C/C++ generic bootstrap used in EKA1 has been replaced with an assembler bootstrap,+
−
which is split into a generic layer usable on any ARM device and a device-specific+
−
layer. </p> </section>+
−
<section id="GUID-858E4DFA-3988-566B-9B9C-614D7D64843D"><title>Chunks per+
−
process</title> <p>The number of chunks per process is limited to 16 in the+
−
moving memory model. This ensures that switching between address spaces operates+
−
in bounded time. </p> </section>+
−
<section id="GUID-4F31E633-3418-5FEF-B034-E4E42D12ECAE"><title>Releasing blocked+
−
threads</title> <p>Threads that are blocked on semaphores and mutexes are+
−
now released in priority order, not in FIFO order. </p> </section>+
−
<section id="GUID-86BE8113-3442-585D-8AA1-622C6A0E5C33"><title>Stricter checking+
−
on the use of invalid handles</title> </section>+
−
<section id="GUID-70A788E3-EDB4-52B5-85F1-083F0C041161"><title>Kernel is no+
−
longer dependent on EUSER.DLL</title> <p>The kernel no longer has any dependency+
−
on EUSER.DLL. Only user side code can link against EUSER.DLL. </p> <p>There+
−
are three main reasons for this: </p> <ul>+
−
<li id="GUID-72571CC2-FFC1-56FF-8B64-C3AEF94F2581"><p>It allows more robust+
−
on-target application debugging, as it is no longer possible to crash the+
−
kernel by putting an application breakpoint in shared code. </p> </li>+
−
<li id="GUID-91726D13-397C-58E8-9405-185D05C13F0E"><p>It reduces the size+
−
of the minimum system configuration. </p> </li>+
−
<li id="GUID-61B6DEAD-42F4-5BBC-9A83-8C038149E114"><p>It allows the kernel+
−
to be built using a different compiler to that used to build the user side. </p> </li>+
−
</ul> <p>This has important consequences for kernel side code. Any code that+
−
runs on the kernel side, including device drivers, cannot use classes, functionality,+
−
or behaviour that is implemented by EUSER.DLL. Although not a complete replacement+
−
for this lost functionality, the Nanokernel and the Symbian platform kernel+
−
do provide a set of utility functions such as <xref href="GUID-E2C25A1E-46B4-3697-A939-613CA366D87A.dita"><apiname>memcpy()</apiname></xref>, <xref href="GUID-5A95E126-A82F-3F29-9810-FA1CD35E8B19.dita"><apiname>memset()</apiname></xref>,+
−
and <xref href="GUID-AC5005AE-EDC0-36EE-B877-2F91B09B0068.dita"><apiname>memmove()</apiname></xref>. </p> </section>+
−
<section id="GUID-14A08FAE-ADA1-55A8-9398-309E7FE517E3"><title>Kernel-side+
−
code no longer leaves</title> <p>Kernel-side code can no longer use the leave/cleanup+
−
stack mechanism. If appropriate, functions must now provide a return code,+
−
and callers need to check return values. </p> <p>Note that this mechanism+
−
is still available on the user side. </p> </section>+
−
<section id="GUID-BCDC2615-0F4A-55A2-8806-0963C2939349"><title>No kernel-Side+
−
support for unicode</title> <p>The EKA2 kernel only provides support for ASCII+
−
strings. </p> <p>All kernel objects such as processes, threads, etc. have+
−
ASCII names. The kernel does use a few unicode strings but it treats them+
−
as opaque types. As kernel object names are limited to ASCII, user-side code+
−
must use only the ASCII subset of unicode when creating such objects. </p> </section>+
−
<section id="GUID-AA9A48C6-5033-5459-AC1A-809FAEFB9001"><title>Kernel-side+
−
code uses DBase instead of CBase</title> <p>Classes that are instantiated+
−
on the kernel heap must now use <xref href="GUID-4FCB6127-84F3-38F6-8AD2-FC3B94D67DA3.dita"><apiname>DBase</apiname></xref> instead of <codeph>CBase</codeph>. <codeph>CBase</codeph> can+
−
only be used by user-side code. </p> <p> <codeph>DBase</codeph> is defined+
−
in <filepath>...\e32\include\kernel\klib.h</filepath> and exported to <filepath>\epoc32\include\kernel\klib.h</filepath>  </p> </section>+
−
<section id="GUID-745A19A0-FA97-5250-B493-C0613EAE162E"><title>Asynchronous+
−
deletion</title> <p>The <xref href="GUID-4FCB6127-84F3-38F6-8AD2-FC3B94D67DA3.dita"><apiname>DBase</apiname></xref> class provides the behaviour+
−
that allows objects to be deleted asynchronously. This is particularly useful+
−
when memory deallocation needs to be done by time critical code. </p> <p>Deletion+
−
is done by placing the object onto a queue and then triggering a DFC, which+
−
runs in the context of the supervisor thread. </p> </section>+
−
<section id="GUID-EBD2C3D9-D422-5EDC-B2DF-BEBE713DFF49"><title>Accessing user+
−
side memory directly not permitted</title> <p>Kernel side code must not access+
−
user side memory directly. Use the functions specifically provided for the+
−
purpose: </p> <p> <xref href="GUID-B56A34CD-E5B5-3E3E-A2EE-3BC9D248B210.dita"><apiname>kumemget()</apiname></xref>, <xref href="GUID-15B62FF1-5D59-3A84-9648-EB0DBFE17232.dita"><apiname>kumemget32()</apiname></xref>, <xref href="GUID-C7AB0391-99D5-31A2-91D4-A7F195546FC3.dita"><apiname>kumemput()</apiname></xref>, <xref href="GUID-D141C3C4-F2F6-37DF-BDF6-63DDE9052FA0.dita"><apiname>kumemput32()</apiname></xref>, <xref href="GUID-B51F91FF-E5CD-3D5F-8BB3-B18E58761B62.dita"><apiname>kumemset()</apiname></xref>, <xref href="GUID-F5136CAF-B66F-388D-A610-D0153CAF7E23.dita"><apiname>umemget()</apiname></xref>, <xref href="GUID-B55573FC-B21C-384A-8B1E-A6A4301310E9.dita"><apiname>umemget32()</apiname></xref>, <xref href="GUID-371860F0-36BF-340D-BEF6-1763EF9874AE.dita"><apiname>umemput()</apiname></xref>, <xref href="GUID-B2DF3520-01CE-3D2C-8137-746ADBCBAE80.dita"><apiname>umemput32()</apiname></xref>, <xref href="GUID-16048974-7407-3778-9BD3-B8417E3F795A.dita"><apiname>umemset()</apiname></xref>, <xref href="GUID-C6946ECB-775F-3EC2-A56F-78F25B9FBE3D.dita#GUID-C6946ECB-775F-3EC2-A56F-78F25B9FBE3D/GUID-C505206F-F54F-3760-BA7D-2DB52AB4E0B3"><apiname>Kern::ThreadDesRead()</apiname></xref>, <xref href="GUID-C6946ECB-775F-3EC2-A56F-78F25B9FBE3D.dita#GUID-C6946ECB-775F-3EC2-A56F-78F25B9FBE3D/GUID-FA321582-6D75-37A1-8DAB-D50638F76593"><apiname>Kern::ThreadDesWrite()</apiname></xref>, <xref href="GUID-C6946ECB-775F-3EC2-A56F-78F25B9FBE3D.dita#GUID-C6946ECB-775F-3EC2-A56F-78F25B9FBE3D/GUID-904A42A8-8077-3FC6-BEF2-29619F079842"><apiname>Kern::ThreadRawRead()</apiname></xref>, <xref href="GUID-C6946ECB-775F-3EC2-A56F-78F25B9FBE3D.dita#GUID-C6946ECB-775F-3EC2-A56F-78F25B9FBE3D/GUID-182C88F4-326C-376E-9FBE-889E3CB9B68A"><apiname>Kern::ThreadRawWrite()</apiname></xref>, <xref href="GUID-C6946ECB-775F-3EC2-A56F-78F25B9FBE3D.dita#GUID-C6946ECB-775F-3EC2-A56F-78F25B9FBE3D/GUID-D7CE1BF2-F1B8-30E9-9D34-7BDDA39C1B0C"><apiname>Kern::KUDesGet()</apiname></xref>,+
−
and <xref href="GUID-C6946ECB-775F-3EC2-A56F-78F25B9FBE3D.dita#GUID-C6946ECB-775F-3EC2-A56F-78F25B9FBE3D/GUID-8B62DE20-357F-3499-9F2E-FAD4B18C34D6"><apiname>Kern::KUDesPut()</apiname></xref>  </p> <p>See also <xref href="GUID-F46B87B7-97A9-530B-BAC4-EF1DB9C91E39.dita#GUID-F46B87B7-97A9-530B-BAC4-EF1DB9C91E39/GUID-4A7BCB91-C58B-597F-85B6-74463BE9BC04">accessing User Memory</xref> in <xref href="GUID-F46B87B7-97A9-530B-BAC4-EF1DB9C91E39.dita">Porting+
−
a device driver from EKA1 to EKA2</xref>  </p> </section>+
−
<section id="GUID-E0313A56-3F85-5614-964A-30972BA0193D"><title>Kernel side+
−
code uses DObject instead of CObject</title> <p>Kernel side objects that are+
−
reference counting, must now derive from <xref href="GUID-E48F1435-14B6-37F1-BE47-2EA803AFE497.dita"><apiname>DObject</apiname></xref> instead+
−
of <codeph>CObject</codeph>. </p> <p> <codeph>CObjectCon</codeph> also has+
−
a kernel-side equivalent <xref href="GUID-7FB9067F-D200-382C-84F7-49F0548D0A7F.dita"><apiname>DObjectCon</apiname></xref>. </p> </section>+
−
<section id="GUID-FADA0E2F-A37B-58A1-93AD-5DEF04ECD0D1"><title>Device Driver+
−
Model</title> <p>The device driver model has changed. See the <xref href="GUID-0437DB4C-FC4E-51DC-BB4C-95C0B26834F5.dita">Device+
−
Driver Guide</xref> for the detail. </p> </section>+
−
<section id="GUID-66C87C5D-D71B-5D98-9B49-C7FD4D18D540"><title>Base porting</title> <p>EKA1,+
−
allows only a single hardware interfacing architecture. The lowest layer of+
−
the kernel contains the ASSP-specific code and a separate variant DLL contains+
−
variant-specific code called by the kernel. </p> <p>In contrast, the EKA2+
−
core kernel, <filepath>ekern.exe</filepath>, is agnostic as regards the hardware+
−
interfacing architecture. It does not contain any peripheral-related code,+
−
and and only requires a variant DLL. The amount of functionality to be provided+
−
by this DLL is much smaller than in EKA1. </p> <p>In general, EKA2 base ports+
−
use one of the following two architectures: </p> <ul>+
−
<li id="GUID-57765CBB-ED06-50FD-8A9D-A972BD1FD517"><p>ASSP+Variant: where+
−
the Variant is split into an ASSP layer (a DLL) and a Variant layer (a DLL).+
−
The first DLL contains all the ASSP-specific / device-agnostic code, and the+
−
second DLL contains the device-specific code. This allows code sharing between+
−
different devices using the same ASSP/ASIC. The interface between the ASSP+
−
and variant DLLs is private. </p> </li>+
−
<li id="GUID-F52159AE-5A0A-5452-A742-F212DF68D948"><p>Variant alone: Both+
−
the ASSP and the device specific code is included in a single Variant DLL.+
−
This saves the effort of partitioning the code if only one device is planned. </p> </li>+
−
</ul> <p>In addition, peripheral-related features that are part of the kernel+
−
in EKA1 (e.g. DMA framework) are now implemented as kernel extensions. </p> </section>+
−
<section id="GUID-FA2341A0-1743-5FE3-9C22-E2575816BE8D"><title>Emulator</title> <p>A+
−
number of changes in the emulator architecture have a system-wide impact. </p> <p><b>Process emulation</b> </p> <p>The emulator supports multiple Symbian platform+
−
processes. This removes the need for WINS-specific code in various places,+
−
notably in server start-up. </p> <p>The emulator still runs as a single WIN32+
−
process, so a Symbian platform process can still accidentally write into the+
−
address space of another Symbian platform process. </p> <p><b>Thread scheduling</b> </p> <p>The emulator uses the same scheduling algorithm+
−
as Symbian platform running on hardware. This is in contrast with EKA1 that+
−
leaves Symbian platform thread scheduling to the Windows kernel leading to+
−
discrepancies in behaviour between the emulator and hardware. </p> <p><b>Calling WIN32 APIs from Symbian OS code</b> </p> <p>Because the emulator+
−
now uses the same scheduling algorithm as native Symbian platform, the Symbian+
−
platform kernel may have to suspend a thread while it is executing some arbitrary+
−
code inside Windows. If the thread holds one or more (Windows) locks when+
−
it is suspended and another thread tries to acquire the same lock(s), a deadlock+
−
occurs. To prevent this, Symbian platform code that calls into the WIN32 API+
−
must use new Symbian platform APIs, <codeph>Emulator::Lock()/Unlock()</codeph> or <codeph>Emulator::Escape()/Reenter()</codeph>.+
−
The impact should be minimal because most of the code interacting with Windows+
−
is in the Base subsystem. </p> </section>+
−
<section id="GUID-B3073835-E9D7-5219-BC63-D7296ABB9B5C"><title>Kernel-side+
−
messages</title> <p>Because the kernel is multi-threaded in EKA2, <xref href="GUID-178E140F-BB15-5A82-99A6-D1BC0E11E018.dita">Kernel-side+
−
messages</xref> offer a means of communication between Symbian platform threads+
−
executing kernel-side code. Typically, they are used by device drivers to+
−
communicate between a client thread, usually a user thread, and a kernel thread+
−
running the actual device driver code. </p> </section>+
−
<section id="GUID-E897C3F8-F275-59F0-BBFC-7981865226F2"><title>Passing handles+
−
&amp; data at process creation</title> <p>In EKA2, handles and binary data+
−
(in the form of descriptors, or integer values) can be passed to a process+
−
at process creation time. Up to 16 separate pieces of information can be passed+
−
to a process on creation. </p> <p>See <xref href="GUID-AD2BD987-E097-5E1F-A914-B91CFB706D51.dita">Passing+
−
handles &amp; data at process creation</xref> for more information. </p> </section>+
−
<section id="GUID-8D788A9A-3AE1-5A5E-9761-5DCC81A60603"><title>Power management</title> <p>The+
−
EKA1 power management framework has been replaced in EKA2 with a new framework+
−
that aims at fixing known issues with the EKA1 one. The main design goal for+
−
this new framework is increased flexibility, i.e.: </p> <ul>+
−
<li id="GUID-03A92EBE-669D-50C1-905B-AA7B9A3FC68A"><p>providing support for+
−
a wide variety of power management hardware </p> </li>+
−
<li id="GUID-FF1E50F6-6DE3-5919-A703-BDA5440E26A1"><p>separating mechanism+
−
and policy to allow different power management strategies. </p> </li>+
−
</ul> <p>As an example of increased flexibility, the set of supported power+
−
states is extensible by licensees. </p> <p>The changes mean that, on the user+
−
side, there is no binary or source compatibility. The impacted components+
−
are app-framework/UIKON and the GUI LAF (e.g. techview/toolkit). </p> <p>On+
−
the kernel-side, there is no binary compatibility. Old-style power handlers+
−
can still be built but if one or more of them are active, the system cannot+
−
switch to standby mode. </p> <p>In EKA2, the power model DLL no longer exists.+
−
EKA2 replaces the EKA1 user-side framework with a new one based on the concept+
−
of domain. A domain is a set of processes that share the same power management+
−
characteristics. </p> <p><b>User-side+
−
changes</b> </p> <p>A new user-side domain server manages all domains in the+
−
system and centralises interactions with the kernel. The main requests supported+
−
by this server are: </p> <ul>+
−
<li id="GUID-63B5CEED-7B05-5F19-A99F-BD51DD144E23"><p>Transition all processes+
−
in a given domain to a new power state. </p> </li>+
−
<li id="GUID-66E37108-73A4-5844-BA3C-5E2FC3C9E1EC"><p>Transition all domains+
−
to a new power state. </p> </li>+
−
</ul> <p>The set of all domains forms a tree. A request to transition a domain+
−
D to a new power state is cascaded down to its children first. D is then transitioned+
−
after all its children have themselves transitioned to the new state. </p> <p>The+
−
domain server is policy-agnostic. It links against a customisable DLL that+
−
provides the policy part. This DLL notably specifies the structure of the+
−
domain tree. Usage of the domain framework is optional. Licensees are free+
−
to replace it with another user-side scheme or to implement all their power+
−
management policy kernel-side. </p> <p><b>Kernel-side+
−
changes</b> </p> <p>The new kernel-side framework breaks down into the following+
−
items: </p> <ul>+
−
<li id="GUID-2E0FC695-8527-59C7-8F56-09C6E9A349FB"><p>A power manager, embedded+
−
in the core kernel, which implements the power management executive calls+
−
and manages the other kernel-side entities </p> </li>+
−
<li id="GUID-5A04F61E-499A-5CE5-B6EF-19FA26517D53"><p>A set of power handlers+
−
implemented within device drivers. When a power transition is requested, the+
−
power manager dispatches it to every registered power handler. </p> </li>+
−
<li id="GUID-5576AC0E-4CB6-544A-A547-674EBFC74513"><p>A power controller implemented+
−
in a kernel extension. It manages the different sleep modes supported by the+
−
CPU. </p> </li>+
−
</ul> <p>The power handlers and power controller are device-specific. A specific+
−
implementation could specify a private interface between these components+
−
to extend the generic framework. For example power handlers could notify the+
−
power controller of state changes so the latter can select the most appropriate+
−
sleep mode. </p> </section>+
−
<section id="GUID-E8321E95-FEE1-516D-8EED-30B6C2C25E18"><title> Support for+
−
alternative heap allocators</title> <p>User mode threads and processes can+
−
now instantiate their own concrete heap allocator classes for use as the default+
−
allocator rather than be required to use the Symbian platform supplied <xref href="GUID-EFAFDD75-7E59-306A-882D-317F5564979E.dita"><apiname>RHeap</apiname></xref> class. </p> <p>This+
−
has been done by defining the new abstract class <xref href="GUID-9DB4A58C-6FC8-3292-A547-4C161BD188FC.dita"><apiname>RAllocator</apiname></xref>. <xref href="GUID-EFAFDD75-7E59-306A-882D-317F5564979E.dita"><apiname>RHeap</apiname></xref>,+
−
now derives from this new class. </p> <p>The new class allows threads and+
−
processes to replace the standard first-fit heap allocator class to improve+
−
allocation performance or solve memory fragmentation problems. </p> <p>The+
−
change has been made to minimise binary compatibilty and source compatibility+
−
impact on existing software. The following standard allocation functions are+
−
completely compatible: </p> <ul>+
−
<li id="GUID-74113B2B-BA3B-57D8-B0E5-7CDB81E9B7A0"><p> <xref href="GUID-B89E4D10-0DFD-3270-B45B-565B01421466.dita"><apiname>operator new()</apiname></xref>  </p> </li>+
−
<li id="GUID-400E98C4-04DC-5608-879B-579D487139DF"><p> <xref href="GUID-05782A1A-60BF-3D6F-AA78-8C1B25E1A3C8.dita"><apiname> operator+
−
delete()</apiname></xref>  </p> </li>+
−
<li id="GUID-317BADC6-0FBB-56A8-9B88-705231ED74AC"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-67554CF1-F7D1-37E3-8088-1625B3FCEBB4"><apiname> User::Alloc()</apiname></xref>  </p> </li>+
−
<li id="GUID-C1A56138-2D40-558D-9A00-221F911974EF"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-C035F07D-B6D9-3A21-A323-DAC89137280D"><apiname> User::AllocL()</apiname></xref>  </p> </li>+
−
<li id="GUID-0D584313-138F-5463-86B8-E5B558A5FE17"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-8944FF54-F874-3340-872B-CF6AD001F694"><apiname>User::AllocLC()</apiname></xref>  </p> </li>+
−
<li id="GUID-84E0415D-66F4-5A61-818F-244790DAD52A"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-A1B58B92-E9B2-3C0F-89B3-BA3230A1E14F"><apiname>User::Free()</apiname></xref>  </p> </li>+
−
<li id="GUID-356C7BD2-81BC-59EB-A626-E7DD4E1698DC"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-076A396B-D9F1-3CB9-8D93-AF2E1D0C9415"><apiname>User::ReAlloc()</apiname></xref>  </p> </li>+
−
<li id="GUID-8C59C1D4-F248-5459-9AB8-B19E5F4316D5"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-7804ECCB-D061-3572-A4C4-A629098F0790"><apiname> User::ReAllocL()</apiname></xref>  </p> </li>+
−
<li id="GUID-A9ABCC69-F7AD-589E-AA3A-B797757C7123"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-AE5D927B-2CFB-3CE0-9EB7-437C4482241F"><apiname>User::AllocLen()</apiname></xref>  </p> </li>+
−
<li id="GUID-A1D29CE1-8D07-5587-8FBF-F9B8903561D5"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-E970D052-A8D6-3430-9E23-EB935DD32335"><apiname> User::AllocSize()</apiname></xref>  </p> </li>+
−
<li id="GUID-D5CDA68B-0172-5A80-99AB-69FFD8985975"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-62895F0B-089D-36F8-81C9-718B3D26585A"><apiname>User::Available()</apiname></xref>  </p> </li>+
−
<li id="GUID-21AB331F-A559-5D6A-8C5A-C0B65CEAF76F"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-6755A02F-524F-3718-AD87-AE4A3BE20D3A"><apiname> User::CountAllocCells()</apiname></xref>  </p> </li>+
−
<li id="GUID-16A3DA52-1513-525A-84B2-B63C85E73DFB"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-B2710076-A191-3F8B-B562-E92AE776549C"><apiname> User::FreeZ()</apiname></xref>  </p> </li>+
−
<li id="GUID-7E64E012-BF78-5618-9B07-112A566E892E"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-82CD000F-BE5C-37EF-9B85-FC0A57570702"><apiname>User::Check()</apiname></xref>  </p> </li>+
−
<li id="GUID-7CD596C5-657A-58D4-91DF-9DE72D5B9CE5"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-04A2474D-0A77-37A7-8567-BB7BC33C3CBE"><apiname> User::CompressAllHeaps()</apiname></xref>  </p> </li>+
−
</ul> <p>The following functions are compatible assuming that the thread has+
−
not replaced the heap allocator with a different object: </p> <ul>+
−
<li id="GUID-7D68B874-0D5B-5432-8F9B-78CAA32B4036"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-E6BB60B3-B367-34EF-B843-3D32568275FF"><apiname>User::Adjust()</apiname></xref>  </p> </li>+
−
<li id="GUID-D3324C8B-3FF1-58AA-86AB-C65CAFB7FA76"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-4DDE6BB9-F0D8-3A0F-8F70-03728E80E26C"><apiname>User::AdjustL()</apiname></xref>  </p> </li>+
−
<li id="GUID-91DF8623-3DF2-5977-B097-FFC6953B7ACA"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-42AC433D-1C9C-3AC6-8640-EB1A7BA876B5"><apiname>User::Heap()</apiname></xref>  </p> </li>+
−
<li id="GUID-D1895B52-9A53-598C-8B64-F97B1956992F"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-D157A678-62BB-3BF8-8166-C9E03F258E2A"><apiname> User::SwitchHeap()</apiname></xref>  </p> </li>+
−
<li id="GUID-F1473064-A52E-511A-91AB-2FC51E01B705"><p> <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-6FA3E28C-49D8-39CD-BFC7-FEAEADE40BA5"><apiname> RThread::Heap()</apiname></xref>  </p> </li>+
−
<li id="GUID-B45BE2A4-944D-51F3-94FA-BC005C8195DD"><p> <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-4A1F473A-A804-3984-AEED-B47ACA79AE49"><apiname> RThread::SetHeap()</apiname></xref>  </p> </li>+
−
</ul> <p>The following functions have been added to support software that+
−
wishes to replace the heap allocator: </p> <ul>+
−
<li id="GUID-B0E30820-C1F2-5A70-8A04-33EA56ED3602"><p> <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-25730109-73AF-3F5A-83F5-EE5FB18A5692"><apiname> User::Allocator()</apiname></xref>  </p> </li>+
−
<li id="GUID-3B23EB7D-D4D5-509A-827A-6853EC7578AE"><p> <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-518DF5B4-3454-32B8-BC3F-F0D47274EF97"><apiname> RThread::Allocator()</apiname></xref>  </p> </li>+
−
</ul> <p> <codeph>RThread::GetRamSizes()</codeph> is now deprecated – the+
−
heap size is always reported as zero, and the stack size should now be extracted+
−
using the new <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-699F8282-62EF-3F13-85DC-5C0F7910A43D"><apiname>RThread::StackInfo()</apiname></xref> API. </p> <p>Software+
−
that is dependent on the layout of the <xref href="GUID-EFAFDD75-7E59-306A-882D-317F5564979E.dita"><apiname>RHeap</apiname></xref> internal data+
−
or virtual function table may no longer work after this change. Such software+
−
is likely to be rare or limited to test code. There is no legitimate dependency+
−
on this information except where 3rd party software has derived a class from+
−
RHeap, but this is considered to be very unlikely for anything other than+
−
test purposes. </p> <p>The default allocator object stored for each heap is+
−
no longer a <xref href="GUID-EFAFDD75-7E59-306A-882D-317F5564979E.dita"><apiname>RHeap</apiname></xref>, but a <xref href="GUID-9DB4A58C-6FC8-3292-A547-4C161BD188FC.dita"><apiname>RAllocator</apiname></xref>.+
−
This means that it is possible that <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-42AC433D-1C9C-3AC6-8640-EB1A7BA876B5"><apiname>User::Heap()</apiname></xref> does not+
−
actually return a reference to a <xref href="GUID-EFAFDD75-7E59-306A-882D-317F5564979E.dita"><apiname>RHeap</apiname></xref> object, possibly+
−
resulting in broken software. However, as the default class used for allocation+
−
is still <xref href="GUID-EFAFDD75-7E59-306A-882D-317F5564979E.dita"><apiname>RHeap</apiname></xref>, then there is no additional impact unless+
−
a thread or process explicitly instantiates an alternative allocator class.+
−
In the latter case, we would expect that the code using the allocator to also+
−
be updated to use the alternative class. </p> <p>The allocator is created+
−
by the owning thread when it first runs, which means that software that depends+
−
on the heap existing before the thread is resumed will no longer work. In+
−
particular calling <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-6FA3E28C-49D8-39CD-BFC7-FEAEADE40BA5"><apiname>RThread::Heap()</apiname></xref> before the thread runs+
−
and creates the heap will return NULL. This was a real pattern found in several+
−
places in Symbian OS code to work around the lack of processes in the EKA1+
−
emulator, where a ‘command line’ is inserted into the created thread by allocating+
−
a cell on the new thread’s heap. This is not an issue for EKA2 as it supports+
−
processes in the emulator and such code should just be removed when adapting+
−
it for the EKA2 emulator. </p> </section>+
−
</conbody></concept>+
−