The Symbian OS (779886), страница 61
Текст из файла (страница 61)
Thus the corekernel is independent of both ASSP and variant. In contrast, in EKA1the separation between hardware-dependent and hardware-independentcode was less clear-cut, and hardware support was less cleanly partitionedbetween the ASSP and variant.It is also important to remember Symbian’s origins as an applicationcentric operating system, which determines additional design goals:• provide a fully programmable platform – enabling user-installableapplications as well as a complete native application set• provide a fully graphical system which is intuitive to use – with fullinteractive GUI, multitasking and instant task switching.From the beginning, Symbian OS has also been strongly focused oninternational markets, with early support for non-Western scripts (forlanguages such as Chinese, Arabic, Thai and Hindi):• Unicode multi-byte characters supported throughout the system• easy localization• non-Roman and multidirectional script display.Increasingly, the application emphasis has evolved from PIM applications (calendars, contacts books and so on) toward high-data bandwidthapplications, including camcorder applications and mobile digital TV,following the trend of increasingly multimedia capable devices.As well as requiring the architecture to support ever higher datarates, this overall shift in the market away from PDA-style productstowards mobile phones has led to an important evolutionary goal and, inparticular, to specific requirements on the EKA2 kernel.
The kernel was tobe capable of supporting typical licensee phone hardware architectures,including one-core and dual-core variants, and Symbian-only as well as‘partner operating system’ configurations (requiring cooperation with areal-time ‘partner’ operating system driving the baseband hardware andsoftware).Arguably the most critical design goal follows from the above: providea highly adaptable and evolvable kernel architecture capable of changein a rapidly evolving technology, product and market context.The strength of the kernel architecture is demonstrated by its stabilityand continued fitness for purpose in the face of rapid change – forexample, the almost complete transformation of the mobile phone in lessthan a decade, from the pre-Symbian OS basic phone of the mid-1990s tothe PDA–phone ‘smartphone’ hybrids with which Symbian OS enteredthe phone market to today’s full multimedia devices.EKA1 AND EKA228311.4 OverviewSymbian OS has a microkernel architecture,1 which means that theresponsibilities of the kernel are kept to an essential minimum.
The designapproach is to implement a minimal set of operating-system primitives inthe kernel, on which higher-level, generic operating system services canbe built, the goal being to keep the kernel small, and therefore fast, andto keep its complexity low, to achieve high reliability and predictability.Simplistically, kernel responsibilities are divided between implementing suitable primitives for use by the higher layers of the operating systemand interfacing to the underlying hardware platform. Surrounding thekernel itself are the additional components required to provide completehardware support.Because the kernel layer is the interface to the hardware platform,it is dependent on the hardware.
To port the operating system to newhardware entails porting the kernel layer. An important design consideration, therefore, is to optimize ease of porting by isolating hardwaredependencies. The design of the kernel and its supporting components ishighly modular, to make porting simpler.An important distinguishing feature of Symbian OS is its optimizationfor ROM-based systems. Symbian OS was designed to be built intodevice ROM and executed in place without requiring loading into RAM,in contrast to more conventional systems (including Linux/Unix andMicrosoft Windows), which are designed to be loaded from the filesystem into RAM before executing.Supporting ROM-based systems has become more complex as memorytechnologies and hardware architectures have evolved to keep pace withthe burgeoning requirements for storage capacity.
The latest releases ofSymbian OS are optimized for multiple hardware architectures and memory types, including the latest NAND-flash-based systems as well as moreconventional NOR flash. On NOR-flash systems, Symbian OS is executedin place (XIP). On NAND flash, which is not byte-addressable, SymbianOS shadows itself to RAM from where it executes. In both cases, itprovides a translation layer to interface the filing system to the flash drive.11.5 EKA1 and EKA2The origins of EKA1 go right back to the first releases of the operatingsystem.
The original architecture of the Symbian OS kernel was driven bythe need to provide a robust platform for a PDA-centric (and, therefore,application-centric) operating system. Almost from its first release, however, Symbian OS has been evolving to meet the high data-throughput1There are some aspects in which it is more hybrid than pure (see the detailed discussionbelow).284THE KERNEL SERVICES AND HARDWARE INTERFACE LAYERand real-time requirements of more communications-centric devices (inparticular, advanced mobile phones).As early as 1998 (i.e.
two years before Symbian OS v6 was released)a ‘real-time’ project began in the kernel team to investigate the issuesinvolved in providing real-time support and to prototype a solution.The eventual result of that work was a new, real-time-capable kernel,EKA2 (also known as EpocRT), benchmarked in terms of its ability todirectly support a full mobile phone signaling stack. It was intended forrelease in Symbian OS v7 and reached the market in Symbian OS v8,becoming the standard kernel in Symbian OS v9. (In Symbian OS v8.1,customers were offered a choice between the EKA1 and EKA2 kernels.)Even so, the new kernel’s initial selling point for customers was probablyless its real-time capabilities than its support for the new Platform Security architecture, which had become commercially necessary.
PlatformSecurity requires kernel support to police security policies as part of itsinter-process communication (IPC) mechanism. While Platform Securitywas introduced in stepped phases to be compatible with the originalkernel, the full features of Platform Security are only available in a systemrunning EKA2.EKA2 was designed to be closely compatible with EKA1. In importantrespects, the two are functionally equivalent, as evidenced by the choiceof using either EKA1 or EKA2 in Symbian OS v8.1. The critical differenceis that EKA2 is designed to offer true real-time behavior.11.6Singleton Component CollectionsThe Kernel Services and Hardware Interface layer consists of the KernelArchitecture block (or blocks, in the case of releases that include both kernel versions) and two singleton component collections (see Figure 11.2)containing components that, while they are not part of the kernel architecture proper, nonetheless can be counted as belonging on the kernelside of the kernel–user boundary.Localization CollectionThis component is a customizable plug-in that implements locale-specificsettings including standard strings (for example, day and month names),LocalisationKernelServices &HardwareInterfaceKernel ArchitectureScreenDriverFigure 11.2 Localization and Screen Driver collectionsKERNEL ARCHITECTURE BLOCK285LocalisationLocaleSupportFigure 11.3 Localization componentsdistance units, currency symbols, date and time formats, collation orders,and so on.
Standard locales, including Japanese and several Chinesevariants, are provided with the system.Locale Support is included in the Kernel Services layer because itimplements various strings used directly by the kernel (e.g. default systemmessages). It is loaded by the User Library.Table 11.1 Localization ComponentsComponent NameDevelopment NameLocale SupportLOCE32 ONGOING, ELOCLScreen Driver CollectionThis component implements the generic operations defined by the BitGDI to manipulate the physical memory map of the device display orbitmap memory map. (Typically, in-memory bitmaps and the displaymemory map are addressed in the same way in hardware, hence acommon interface is provided to both.) It supports dual screens, whichfeature in flip-phone designs.
The Screen Driver forms part of a base portto new hardware.Table 11.2 Screen Driver ComponentsComponent NameDevelopment NameScreen DriverSCREENDRIVER11.7 Kernel Architecture BlockIn one sense, the Symbian OS kernel has always been larger than amicrokernel, since in both EKA1 and EKA2 it includes extensions andScreen DriverScreendriverFigure 11.4Screen Driver components286THE KERNEL SERVICES AND HARDWARE INTERFACE LAYERKernelServicesLogical Device DriversASSPVariantKernelArchitectureFigure 11.5 Kernel Architecture block in Symbian OS v9device drivers. In another sense, in EKA2 (see Figure 11.5) it is evensmaller, with a true nanokernel at its core.However, both kernel architectures have true microkernel properties.
For example, major services such as the File Server and the UserLibrary, as well as all graphics and communications services, includingnetworking and telephony, remain outside the kernel and are run asuser-side processes. This is in contrast for example to the monolithickernel architectures of both Linux and Microsoft Windows.A microkernel limits the kernel responsibilities to a small set of corefunctions, and builds higher-level operating-system functions on top ofa small set of kernel primitives.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
