The Symbian OS (779886), страница 57
Текст из файла (страница 57)
These includeprocesses, threads and memory chunks and mutexes, semaphores andmessage queues. The User Library also implements many other programming idioms specific to Symbian OS, including active objects anddescriptors, the cleanup stack, the client–server framework, and thePublish-and-Subscribe mechanism.
It supplies an assortment of utilityclasses, including timers, date and time services and locale definition andcollection classes, including arrays, lists and binary trees. It defines thenative data types, both class-based and manifest constants, and suppliesthe libraries that implement the low-level system and language bindings,including DLL and executable entry point stub classes.In the original kernel architecture of Symbian OS (EKA1, beforeSymbian OS v9), the User Library was called from both user-side andkernel-side code. In order to guarantee time bounds, the EKA2 kernel-sidecode does not link to the User Library but instead uses a small utilitylibrary (incompatible with the user-side library) accessible only by thekernel side.The User Library includes the following APIs:• the native types used in the system which include C++ base classes(including CBase) and manifest constants (TInt and others)• collection classes (buffers, arrays and lists), descriptors, Unicodecharacter support, raw-memory management (copying and filling)and geometric concepts (points, sizes, rectangles and regions)• math libraries including 64-bit integers and floating-point math260THE BASE SERVICES LAYER• idioms specific to Symbian OS including the cleanup stack, descriptors, active objects, UID manipulation, and implementations ofmemory allocators, named and reference counted objects and bitmapallocators• other useful classes supporting lexical analysis, bitstreams, Huffmancompression, timers and timing services.In addition, it supplies libraries that provide DLL global data and staticdata and thread local storage; and executable and DLL entry point support(for example calling static constructors).The User Library also provides the Publish-and-Subscribe mechanism(since Symbian OS v8), as a means of storing system-wide global variablesand a platform-security safe IPC mechanism (again, since Symbian OSv8) for peer to peer communication between threads in the operatingsystem.
Publish and Subscribe is based on the notions of properties (datavalues), publishers (threads with rights to update given properties), andSubscribers (threads interested in changes to given properties). Becauseit is available on both user-side and kernel-side, it also provides apossible asynchronous communication mechanism between user-sideand kernel-side code.The File ServerThe File Server provides the framework architecture supporting the implementation of file systems as custom plug-ins and the default plug-inimplementations for FAT file systems, the native format for externallyvisible drives, for example, those implemented on removable media, aswell as internal-only formats such as Read Only File System (ROFS),the internal file system to which ROM code is copied for execution inhardware architectures that do not support execute-in-place memory.File-system plug-in implementations may in turn be further extendedvia extension DLLs to support specific hardware differences, for exampleFAT on NAND flash, which implements a NAND flash translation layertransforming requests coming from the FAT file system into a formatsuitable for a NAND flash-media driver.
Note that the file server ismultithreaded (since Symbian OS v9), using one thread per storagemedium used.The File Server also provides some file-related utility functions, forexample FAT filename conversion which supports translation from fullUnicode file names to ASCII. (While EKA1 supported Unicode stringsinternally, the real-time EKA2 kernel uses only ASCII strings internally;note that there is no impact on the full, system-wide support for Unicode.)The file server has traditionally had an additional role in Symbian OS,as the first of the system services to be started by the final stage of the kernelboot process. In Symbian OS v6 and v7, the file server was responsibleARCHITECTURE261for starting the Window Server, in effect completing the boot process.From Symbian OS v8, the File Server instead launches the System Starter,which performs final initialization of the File Server including adding andmounting file systems on appropriate local drives, and then initiates startup of the rest of the system, including implementing the customizableserver start-up policy (which defines which servers should be started andin which order).Essential System FrameworksThe Base Services layer includes some essential system frameworks,including the Plug-in Framework, which underpins the Symbian OSframework–plug-in architecture, and the persistent storage model.Plug-in frameworkThe Plug-in Framework, known as ECOM, has two principal purposes:to make it easier to design and implement new services or features asframework plug-ins by providing a standard (and best-practice) patterntogether with ready-made run-time support.
Framework plug-in architectures improve the overall modularity, extensibility, and customizability ofthe system, thus improving usability (from a system perspective) as wellas improving design consistency. As importantly, it provides an evolutionpath for already conforming framework plug-in components to migraterelatively painlessly to the platform security model introduced in SymbianOS v9, making it easier for components to adopt the required securitypolicies (i.e.
to ensure trust between frameworks and the plug-ins theyload and to avoid plug-in loading being exploited to subvert platformsecurity).ECOM defines an interface to which all plug-ins conform (plug-insderive from the ECOM base classes) and provides the dynamic discoveryand instantiation mechanisms which find, create, and load them ondemand.ECOM’s original design was evolved from the design of the WAPbrowser framework plug-ins. Broadly, it provides:• methods for defining and implementing interfaces as DLL plug-ins• plug-in registration and methods for managing multiple interfaceimplementations, including plug-in ‘upgrades’ (later versions)• fast dynamic discovery and instantiation methods for plug-ins, as wellas static registration for known system plug-ins• capability policing, that is, enforcement of the security restrictions ofits clients262THE BASE SERVICES LAYER• other features including support for easy localization of plug-ins andstart-up state awareness (to improve system boot-up performance).ECOM was first introduced in Symbian OS v7 and was then significantly enhanced in Symbian OS v8, to support and conform with thenew platform security model.
Initially it offered an optional, standardmechanism for frameworks to define plug-in interfaces and a standardplug-in registration and loading mechanism. Subsequently it was elevatedfrom an optional to an obligatory mechanism; from Symbian OS v8, itis the standard interface used by all frameworks to define how plug-insinteract with and extend the framework and the global runtime bindingmechanism that finds and loads plug-ins into requesting frameworks ondemand, while conforming to the Platform Security requirements andlimitations on processes.Security issuesECOM ensures that frameworks are only able to find plug-ins they havethe capability to load and which pass the platform security check, thatis, matching of the DLL UID field from the RSC resource file to the SID(secure identifier) of the corresponding DLL.6 Plug-ins are loaded intothe requesting client framework’s process, allowing the kernel to policethe capabilities of the plug-in DLL.
(Although if the plug-in’s capabilitiesdo not match those of the client process, then it could be loaded into aseparate process.)ECOM is implemented with a standard client–server architecture,based around a central registry (of interface implementations) and aserver client-side API that handles inter-process communication (IPC)between servers and their clients (wrapping the invocation parameters,passing the wrapped request over the IPC boundary and unwrappingany return parameters when a call completes). Client frameworks use asession object as the interface to the ECOM server for finding, creatingand destroying plug-in providers of the framework interface.Calls to the ECOM server are translated into registry or load calls toperform:• addition and removal of interface implementations (registrar functions)• access and persistence mechanisms (registry data functions)6Strictly speaking the UID3 of a DLL is not really the SID, since SIDs are only assignedto executables or processes (based on the executable’s UID3) and not to DLLs.
Also anysingle DLL can potentially contain multiple different implementations of a given interface,which would share interface UIDs but differ in implementation UIDs. [Heath 2006] is thebest reference for following up the details.ARCHITECTURE263• resolution and searching mechanisms returning ‘best fit’ results(resolver functions)• loading and unloading (load manager functions).A single instance of the registry exists.
Registry data is held in twoforms, an internal format for fast access, consisting of a subset of the fullregistry data, and persisted data, consisting of the registration set storedin file form, divided into branches with one branch per available drive(branches may be transient, supporting removable media).Client frameworks (i.e. interface definers) may supply custom resolverimplementations to ECOM to implement custom criteria.Full discovery of plug-ins occurs at ECOM server start-up, that is, atdevice boot time.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
