The Symbian OS (779886), страница 92
Текст из файла (страница 92)
The introduction of system-wide platformsecurity was similarly phased in over two v8 releases: v8.0 and v8.1. (Itoverlapped with the introduction of the new kernel because it dependedon the new kernel to police the security policy implementation.) Both areexamples of a major re-architecture of the system and both cases reflectSymbian’s perception of the needs of the market. Interestingly, in bothcases there was some short-term customer resistance, even if customershave later embraced the changes.David Wood:It has taken a long time for EKA2 to come to fruition, but that has been aninternal renewal of Symbian OS and that is an extremely important initiativethat’s happened, because it has addressed some of the things that, over thecourse of time, it became clear to us were shortcomings in the original design.So it’s very good that we’ve been able to do that.
I don’t think the fullsignificance of the new kernel will be appreciated for some time, but we willsee it employed not just in smartphones, but in a large number of other mobiledevices too in my view, because of what we were able to do to refresh thedesign.Platform Security is a highly significant change, which introduces asecurity capability model and data caging supported by a certificationscheme, and requires some significant kernel changes including changesto IPC.
The overall impact has been high and, in platform terms, is highlyvisible, because it has immediate (external) developer impact. Again, theproject had to weather some significant early resistance. To some extent,the external impact may not yet have been fully felt. Charles Davies issanguine.Charles Davies:It’s a big thing, you know. There is no industry-wide accepted best practice forhow to secure a system, I think nobody knows exactly what the best thing isto do.
There is no ‘right’ answer. But PlatSec is our answer and time will tell.17.4Evolution in the KernelThe move to the new EKA2 kernel is perhaps the most significantevolutionary step Symbian OS has taken. However, as Martin Taskerpoints out, architecturally it remains in some ways quite a local change.EVOLUTION IN THE KERNEL437Martin Tasker:At the system-design level, it hasn’t actually radically changed the systemdesign. It’s still either application processes or server processes and that designwas pioneered way back in SIBO and hasn’t changed much since the earliestreleases of EPOC.
One reason it hasn’t changed much is that it’s a provendesign.In fact, the beginnings of the kernel re-architecture go all the way backto the first collaboration with Nokia on the project to bring the 9210Communicator to market.
This was not Symbian’s first licensee projectand it was not the first Symbian OS phone project.2 However, at the timeit was certainly the largest and most complex Symbian project to date.The design approach was based on a two-operating-system, twoprocessor solution, the so-called ‘partner operating system’ approach.Symbian OS, since it was not then real-time-capable, was not capable ofhosting the GSM telephony stack. The phone side and the application sidewere therefore separated, with a dedicated RTOS running on a dedicatedphone-side processor and hosting the baseband software, while SymbianOS hosted the application side, running separately on an application-sideprocessor (see Chapter 15). While Symbian OS has evolved hugely in theintervening years (probably almost as much as the phone hardware hasevolved from the first, brick-like Communicator design to the latest sleekdevices), the problems of that early solution are instructive.
The mostimmediate problem was how to force the phone-side RTOS and SymbianOS to cooperate.Morgan Henry:To integrate the two OS schedulers and interrupt handing, there was only asmall amount of management that EPOC did first and then it would call one ofthese hooks to hand-off to the RTOS. The RTOS would only give control backonce it felt it had done its job. I believe there have been similar solutions forthings like Linux running with a partner RTOS.
But the challenges aren’t overyet and you have to decide what owns which bit of hardware. Some of thehardware was owned by the RTOS and some of it was owned by EPOC. I thinkthe MMC card, for example, was owned by EPOC and all of the peripheraldrivers, but all of the baseband hardware was on the RTOS side, so it ownedthe power management, and it owned the real-time clock which caused someinteresting problems.Coming from the Series 5, where EPOC always had direct access to everybit of hardware, especially the real-time clock and the timers, and now finding2The Philips Ilium/Accent and the Ericsson R380 projects both preceded it, though onlythe R380 came to market.438SYSTEM EVOLUTION AND RENEWALthat it had to go over a communications protocol to get the time from thereal-time clock was a bit of an architectural shock for it.
So there were lots ofwork-arounds, but where we had the opportunity to do it we tried to redesignin a sane way. This is what started the move to try and push a lot of thingsoutside the kernel and shrink its responsibilities. For example, the kernel beingable to persist system settings is something that was possible on the Series 5because it had battery-backed RAM available to it, so it was persisting datain the superpage and so on.
This wasn’t really possible in the Nokia 9210model where a lot of that data was owned by the RTOS and persistent storagerequired writing to flash memory. So there were improvements in how wedid the HAL [Hardware Abstraction Layer] to move from the Series 5 model,where a lot of the responsibility for persisting was with the kernel and the UserLibrary. In the new world a lot of that either got pushed up higher into theoperating system or got pushed over to the RTOS.Those were just some of the challenges of the partner OS approach, becauseit was a fairly difficult piece of hardware sharing.
For example, because wedidn’t have visibility of what was going on inside these RTOS hooks we’dget defect reports or see problems on the hardware which were kind ofinexplicable. You quickly realized you needed someone in the kernel teamwith a big brain to think hard about the problem and discover that it wouldbe that the RTOS was affecting the processor state in ways it shouldn’t, orblocking interrupts when it shouldn’t.Other basic differences between the Nokia 9210 hardware and theoriginal Series 5 hardware design also required some significant changes.Morgan Henry:In terms of architectural changes, new functionality was certainly added; thingslike generic support for the DMA controller and power management, as wellas drawing the delineation between the kernel’s responsibilities and higherlevel responsibilities, for example, in terms of persistence of data.
Those kindsof architectural changes were happening then and those have been carriedforward into the new kernel as well. So those decisions were the right ones atthe time.Another explicit goal of the EKA2 kernel architecture was to improveportability of the operating system by improving the modularity of thekernel design, so that hardware dependencies were isolated from commonkernel code and so that different levels of hardware dependencies wereisolated from each other, for example, to distinguish between moregeneric dependencies and the specific dependencies of particular devices.The so-called ‘partner operating system’ solution is of course onlyone approach to solving the phone problem.
Another goal of the newkernel architecture was to enable single-operating-system and, therefore,single-processor-core solutions.EVOLUTION IN THE KERNEL439Morgan Henry:If you look at the problem we were trying to solve with partner OS, now withthe new kernel we are in a situation where we’ve solved it in a better way.It certainly is a lot more architecturally sound. So the reference design teamin Symbian recently announced that they’d got their first single-core-solutionrunning using Symbian OS as the real-time OS with a personality layer.
Interms of functionality, they’re at the same place but with a better solution, amore robust solution.In this approach, a ‘personality’ layer is used to interface the basebandstack directly to the EKA2 real-time nanokernel. The personality layermimics the interface of the RTOS for which the particular baseband stackwas written. Since the nanokernel has true real-time performance, thissolution allows the baseband to be hosted on Symbian OS along with theapplication side, for which the extended EKA2 kernel (i.e. the nanokernelplus kernel) provides the interface, enabling a single-operating-system,single-core solution.As well as the new kernel architecture, there have been significantother additions to the lowest levels of the system over multiple releases.
Anew framework for power-state management has been added to supportthe latest generation of phones which incorporate hardware previouslyfound only on high-end laptops and dedicated devices such as digitalcameras and camcorders, but still need to provide phone-style extendedbattery life.Radio technologies, such as Bluetooth, Wi-Fi and 3G, are extremelypower-hungry (power drain and battery problems were among the earlytechnical hurdles that stalled the rollout of 3G networks).
Coupled withthe motors needed to drive optical zoom lenses, electronic cameraflashes and large LCD displays, the power demands of high-end phonesreally do push the limits of battery-management technology. Simplisticthree-state models (on, off and standby) which were adequate for anearlier generation of phones no longer meet the requirements. SymbianOS has been very successful at maintaining its significant lead overless-well-adapted operating systems running in mobile phones.3Similarly, there have been substantial changes to keep pace with evolving generations of flash-memory technology, matching the demands of thelatest phones for large removable (and non-removable) drives that providemultigigabyte internal and removable memories.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
