The Symbian OS (779886), страница 63
Текст из файла (страница 63)
While the interface is defined by the User Library, theunderlying mechanism is a kernel-side software interrupt dispatch tablethat decodes software interrupts generated by invocation of the CPUsoftware interrupt instruction into a specific executive call.
From the userside, the mechanism is entirely wrapped by methods of the User Librarystatic classes.Inter-Process CommunicationIPC is supported by an asynchronous message-passing mechanism, basedon Executive calls, which is the basis for client–server communications, aswell as inter-thread communications used in system-level programming(for example, device-driver programming). EKA2 also introduces IPCbased on message queues, which is distinct from client–server IPC, andenables shared chunks.Publish and SubscribeEKA2 introduces Publish and Subscribe, a mechanism for defining globalproperties whose values may then be ‘published’, that is, updated bythe property owner, to ‘subscribers’ who have a dependency on thevalue.
Publish and Subscribe is, in effect, a system-wide asynchronousnotification mechanism to which interested clients can subscribe totrack the changing values of arbitrary properties. Broadly speaking, it isan asynchronous IPC mechanism although, more precisely, it is reallyan inter-thread mechanism, since both publishers and subscribers arethreads.Properties are single data values, that is 32-bit integers or ‘string’ values(strictly speaking, descriptors that contain byte or text data, includingKERNEL ARCHITECTURE BLOCK291Unicode text) of up to 512 bytes in size. Larger property arrays of upto 64 KB can also be defined but do not have the same deterministicoperation.Real-Time ProcessingIn EKA1, the kernel is single-threaded.
In EKA2, the kernel is multithreadedand all threads are pre-emptible. Interrupt latencies and process switchingare time-bounded (whereas they are potentially unbounded in EKA1).Memory ModelIn EKA2, all MMU-related code is moved into a separate module (the‘memory model’), which is linked against the kernel at build time. (EKA2also uses a different memory-map base address.) The kernel itself is thusMMU-agnostic.
The following memory models are supported:• the moving model (ARMv4 and ARMv5 architecture) is functionallyequivalent to EKA1; it uses a single memory-page directory withinwhich entries are moved when address spaces are switched• the multiple model (ARMv6) uses per-process memory-page directories• the single model has no address-space paging but uses a single addressspace (it is used with CPUs without an MMU or to simplify the earlystages of porting)• the emulator model for memory management on a PC.Device-Driver ModelIn EKA2, the device-driver model is made more flexible to allow multipleuser-side client device-driver requests to be handled by a single kernelthread, which in effect serializes access and therefore simplifies devicedriver programming.Device drivers are DLLs that allow code running in Symbian OS tocommunicate with hardware in the variant or kernel extensions.
Devicedriver DLLs are loaded into the kernel process by explicit load commandsfrom the user side. (In contrast, kernel extensions are automatically loadedduring the kernel boot process.)User-side code accesses a device driver through a specific API providedby the kernel, which provides functions to open a channel to a devicedriver and to make requests. These functions are protected and thedevice-driver author provides a derived class to implement functions thatare specific to the device driver.292THE KERNEL SERVICES AND HARDWARE INTERFACE LAYERDevice-driver DLLs come in two types – logical (LDD) and physical(PDD) device drivers. Logical device drivers provide an abstracted representation of hardware and typically support functionality common toa class of hardware devices.
Physical device drivers support specificdevices. Thus, for example, there is a single serial communications LDD(ECOMM) that supports all UARTs, providing buffering and flow-controlfunctions. On a particular hardware platform, different physical UARTS(for example, RS232 and infrared) are supported by device-specific PDDs.PortingModularity is improved in EKA2 and more flexible porting strategies aresupported.
Changes to the ROM building tools also enable greater ROMbuild-time (rather than compile-time) customization.EmulatorThe EKA2 Emulator is written as a true port of Symbian OS to a (virtual)hardware platform and, in that respect, is like any other variant port.This is unlike the EKA1 emulator implementation, which mapped nativeSymbian OS system services to their best equivalents on the MicrosoftWindows host (i.e. trying to make the Symbian OS kernel API workon Microsoft Windows, so that the underlying services, including thescheduler, are all Microsoft Windows services).As a result, the EKA2 emulator is a much more faithful representationof Symbian OS although, since Microsoft Windows forces the emulatorexecutable to be a single process, the emulator must use MicrosoftWindows threads to emulate Symbian OS processes.
A deliberate goal ofthese changes is to make it easier to implement an emulator on platformsother than Microsoft Windows.Power ManagementEKA2 introduces a new power management framework, which is intendedto improve flexibility by supporting a wider range of hardware and byseparating policy from mechanism.
The new framework is based on theconcept of power domains. (A domain is a set of processes that share thesame power management characteristics.)A user-side domain server provides a single point of interaction withthe kernel. Policy (the definition of power states) is implemented in acustomizable DLL.On the kernel side, a power manager is embedded in the core kernel,which implements the power-management executive calls.
An ASSPspecific power controller is implemented in a kernel extension andmanages the different power states and sleep modes supported by theASSP.KERNEL ARCHITECTURE BLOCK293SDIO SupportThe MMC/SD bus controller is extended in EKA2 to support SDIO cards(SD cards that provide an interface to a hardware device as well asmemory).
For example, an SDIO card could provide access to a cameraand to some memory.Unicode SupportUnicode strings are not directly supported within the EKA2 kernel, andtherefore all kernel objects (processes, threads, and so on) have ASCIInames, implying that user-side code should use only the ASCII subset ofUnicode when creating such objects.User LibraryIn EKA2, the User Library is available only on the user side and a kernelspecific utility library is used on the kernel side. In EKA1, both user-sideand kernel-side code were linked against the User Library DLL.Summary of Major Kernel Differences• EKA2 offers real-time support.• EKA2 supports alternative memory models.• Device-driver implementation in EKA2 is simplified by supportingan alternative, serialization approach to handling multiple user-siderequests in a single kernel thread (in the case where multiple devicedrivers share a kernel thread, which is optional).• EKA2 includes improved modularity and greater flexibility for porting, a new power-management model, emulator improvements, andsupport for SDIO cards.• EKA2 does not support Unicode strings inside the kernel and the UserLibrary is available only on the user side.
(The kernel implements itsown User Library subset.)Overall, there are some small system-wide impacts from these changes:• EKA2 threads use more RAM than EKA1 threads (4 KB to support aper-thread kernel-mode stack)• In EKA2, memory chunks are limited to 16 per process (for the MovingMemory model, in order to support deterministic operation althoughcontext-switching times remain nondeterministic). For the Multiple294THE KERNEL SERVICES AND HARDWARE INTERFACE LAYERMemory model, there is no chunk limit and, in addition, it providesfast, deterministic context switching.Hardware Interface, Base Porting and Reference HardwareKernel extensions provide the interface to the platform hardware (thedevice-driver model provides the interface to specific devices).
Themodular, extension-based architecture is designed to allow for flexiblecustomization when moving the operating system to new hardware.In particular, it is designed to enable generic platform dependenciesencapsulated by the Application-Specific Integrated Circuit (ASIC) orASSP, for example, processor type, MMU architecture and standardperipherals such as DSPs and LCD drivers, to be isolated from thedevice-specific hardware such as the flash-memory interface.Platform dependencies are typically encapsulated as ASSP dependencies and device-specific dependencies as ‘Variant’ dependencies.• An ASSP extension module implements hardware-dependent supportfor a given ASSP.• A device-specific ‘variant’ extension module implements other devicespecific hardware support, for example, for peripherals that are notstandard to the ASSP.• Other standard extensions include the power framework and theperipheral bus and USB controllers.To provide a reference point for porting work, each release of SymbianOS is built and warranted against the hardware reference platform.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
