<?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>