The Symbian OS (779886), страница 77
Текст из файла (страница 77)
But from the point of view of saying, ‘Are we utilizing virtualfunctions and polymorphism substantially?’ – well the kernel has got one ortwo examples of it, the key one really is the device-driver framework, whereyou have a base class which represents the basic device driver and devicedriver-channel, and then a real device driver which implements a concretedevice-driver object and device-driver channel. But, on the whole, that isn’treally used in the rest of the kernel, for the good reason that the rest of thekernel is a closed system, and there is not a great deal of value to be added bypursuing that kind of design extensively.There are some other choices that Colly Myers made which areinteresting.Geert Bollen:Colly Myers decided to use polymorphism for implementing the differencesbetween the target machine and emulator implementations.
For example,DThread is the abstract base class and you have a derived emulator threadclass and a derived on-the-metal thread class. I’m not so convinced about that.Bollen’s objection is that polymorphism in this case is the wrongconcept to apply.Geert Bollen:I’m not convinced, because it’s using a dynamic binding mechanism, that is,polymorphism, to represent a static property of the system, that is, whetheryou are an emulator build of the system or an on-the-metal build of the system.You don’t need to do that at run time. In fact, you really don’t want to do thatat run time. That could as well be a compile-time or link-time binding.Using a complex mechanism where a simple one would do (as Bollensays, ‘A typedef would do it: #ifdef baretothemetalthread. .
. ’)seems to break a basic design principle, though no doubt there was a366THE USE OF OBJECT-ORIENTED DESIGN IN SYMBIAN OSreason for the decision when it was made. But there is a deeper point,echoing one previously made.Geert Bollen:Modeling the computation, making that literal and the operations that youdo is still an interesting choice. And it points out something else which wasgoing on, the desire in the architects to constrain the design choices, to havea limited number of patterns in the system. This is an OO system, so let’s useOO mechanisms.
There’s some possible impact on runtime? So?15Just Add Phone15.1 IntroductionMobile phones are uniquely complex devices: more complex than PDAs;more complex by far than PCs. This case study looks back to the criticalearly points in the evolution of Symbian OS into a fit-for-phones operatingsystem. It looks at why phones are different, what particular challengesthey pose and the impact of those challenges in shaping Symbian OS.It is often said that Symbian OS was ‘built for mobile phones’ and theclaim, while true, does not remind engineers of the roots of the operatingsystem. Its predecessor, EPOC, was conceived and implemented first asa mobile operating system for PDAs, even though, by the time it firstshipped, mobile telephony had been identified as a critical market inwhich the operating system would win business and work was wellin hand – driven by phone licensee collaborations – to put Symbian OSinside phone handsets.As this case study shows, the shift in emphasis from PDAs to phonesinvolved some very real challenges.
Understanding what those challengeswere helps us to build a deeper understanding of what Symbian OS istoday.15.2 Anatomy of a Phone‘Mobile phones’, says David Wood, ‘are just irreducibly complex.’ Heshould know. As one of the five founding directors when Symbian wascreated,1 Wood took responsibility for the Technical Consulting arm ofthe company – with a mission to support licensees, old and new, to create‘great phones’ on Symbian OS. Technical Consulting has always been atthe forefront of the process of securing licensees’ use of the system andfollowing through to shipped products.1The others were Bill Batchelor, Colly Myers, Stephen Randall and Stephen Williams.368JUST ADD PHONEDavid Wood:There’s no getting away from the fact, it’s not Symbian OS that makes smartphones complex. Smartphones are complex simply because of the enormousnumber of different technologies that are contained in every single smartphone.Compared with PCs or even PDAs, phones pack an astonishing numberof different technologies into a tiny package.
The things which in a PCare peripheral become integral in any pocket device; screen, keyboard,speakers, microphone and soundcard are packed in with CPU coreand memory and permanent storage. But phones, of course, go further.There is the phone radio hardware itself and possibly multiple otherradio interfaces, such as Bluetooth, and their associated software stacks,full networking, and a complete multimedia system. Megapixel cameraswith true optics have arrived (Zeiss lenses, for example, and opticalzoom) as, of course, has stereo sound with real-time compression anddecompression for stereo playback. Integrated high-definition TV is themost recent arrival, hard on the heels of Wi-Fi, with Wi-Max waiting inthe wings.
Add in the power-management technologies needed to deliverlong battery life while fueling this impressive array of technologies withever-increasing processor speeds yet also avoiding the device becoming(literally) hot in the user’s pocket; the PC, in comparison, starts to looktrivial.Looking back, the hardware architecture of the early devices forwhich Symbian OS was originally designed now looks remarkably simpletoo. A hardware schematic of the Psion Series 52 shows little morethan an ARM core connected via a data bus to ROM, DRAM, andremovable media-card memory, with direct connections to the remaininghardware: an audio codec for microphone input and speaker output, RS232 and infrared UARTs, LCD screen and digitizer overlay (via an analogto-digital converter) and keyboard (via parallel I/O pins).
A power supplyunit drives the system from two standard AA batteries and a wristwatchstyle flat cell backup battery. Interestingly, the Series 5 hardware wasitself more complex than that of some competitors, for example, Apple’sNewton or Motorola’s Magic Cap devices [Wolf 2001, p. 548].15.3The Phone Operating SystemA phone operating system must manage complexity at a number of levels.• It must manage the sheer hardware complexity of a converged devicebut, more specifically, it must manage a double platform: a highly specialized, data-centric (including voice data3 ) radio hardware device on23[Furber 2000, p. 366] shows just such a schematic.Voice-centric GSM/2G has morphed into data-centric 3G.THE PHONE OPERATING SYSTEM369the one hand and a multimedia-ready, networked, application-centricdevice on the other.• It must cope with the sheer software complexity and, more specifically,a double software stack: specialized communications and data-centricprotocol stacks and real-time channels on the one hand and a GUIbased, friendly, application-rich consumer system on the other.• It must deliver the performance expectations of a general consumermarket (toasters ‘just work’ and so phones had better ‘just work’: whenthey stop working, they are thrown away), quite different from theexpectations of users of desktop computers, PDAs or gadgets.• It must conform to the usability expectations of a general consumermarket (no one expects to read the manual for a toaster; why shouldthey read the manual for a phone?), again quite different from specialistusers.• It must stay fit and keep up to date with rapidly evolving technologies,a rapidly evolving network-services (operator-services) infrastructure and evolving open standards (often multiple, competing globalstandards).Depending on who you talk to, ‘phonification’ means different thingsbut, in principle, it means all of the above.
‘Being a phone’ is differentfrom being merely a small, pocketable, mobile device.Architectural ImpactsThe impacts on the system architecture of the move from PDAs to phonesare worth examining.• The most obvious impacts are on the Kernel Services and HardwareInterface layer.
The Kernel itself must either support the real-timeneeds of the baseband or it must be made amenable to an alternativesolution. It must also support licensee ASIC or ASSP custom chippackages, which may mean supporting alternative memory modelsand memory-hardware architectures. It must support phone-specificdevice peripherals, including screens and keypads and possibly dedicated hardware such as a phone flip.• In the Base Services layer, the File Server must support multiple filesystem architectures and media types (both NOR and NAND flash, forexample, and probably also hard drives), providing specialist servicessuch as wear-leveling (for NAND) and demand paging.• In the OS Services layer, the Comms Services architecture must supporttelephony protocols and integrate with networking support; graphicsand multimedia services must support phone use cases (such as370JUST ADD PHONEcamera-phones and music-player-phones); connectivity requirementsare probably also different between PDAs and phones.• The Application Services layer is significantly affected too, with thedifferent phone use cases for applications and new services requiringsupport.• Finally, the UI Framework must provide support for a dedicated phoneuser interface.There are almost certainly other system-wide impacts:• system performance characteristics are likely to be quite different fora phone and a PDA• greater modularity in the system may be necessary to enable thedifferent product cycle for phones (a more platformized model, inother words) and a full product matrix• adaptation almost certainly becomes more complex, with a muchgreater range of technologies needing integration (web browsers,viewers for content such as Flash and PDF, and Office file viewers,font technologies, etc.) and plumbing to close hardware support• service assumptions turn into architecture headaches; phone operatorsare simply not used to open network models (third-party softwareavailability, for example) and a system-wide security model becomesa requirement.Supporting the BasebandThe mobile phone ‘baseband’ is the software signaling stack that acceptsa data stream (e.g., the output from a digital signal processor which hasbeen fed voice input from a microphone) at the top layer and emits astream of encoded data frames at the bottom layer onto a data channelto radio–air-interface hardware and vice versa; accepting encoded dataframes at the bottom and emitting a data stream at the top (if it is voicedata, it is fed to a DAC for conversion to audio output).The signaling stack sits on a software layer of some kind, traditionallya real-time operating system (RTOS), which in turn drives the basebandprocessor, typically a general-purpose CPU such as an ARM or StrongARMdedicated to the RTOS and the stack that it hosts.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
