The Symbian OS (779886), страница 17
Текст из файла (страница 17)
(Available since Symbian OS v7.0sbut universally enforced since Symbian OS v8.0 as part of the phasedintroduction of Platform Security.) The plug-in framework (also known asECom) standardizes the mechanisms and protocols that allow frameworksto locate and load the plug-ins which provide their implementations, andfor plug-ins to register their presence and availability in the system asimplementation modules.Clearly, plug-ins pose a potential security threat because they providea mechanism for untrusted (that is, externally supplied) code to beloaded into the processes of some system components (although themicrokernel architecture keeps them well away from the kernel).
Theplug-in framework therefore enforces the security model on plug-insbefore they are loaded [Heath 2006].Another area in which plug-ins pose potential risks to the system is inperformance. Potentially, a badly designed or poorly implemented plug-incan damage the performance of the framework that loads it. The plug-inmodel can also make it hard to understand the dynamic behavior ofthe operating system and, in particular, can make system-level debuggingtricky, since the system can become (from the perspective of the debugger)highly indeterministic, unpredictable and unreproduceable.However, enabling a pervasive model of run-time rather than staticloading can boost system performance. Plug-ins are loaded on request;if they are not requested, they are not loaded, saving loading timeand system resources (including RAM, on systems that do not provideexecute-in-place).An interesting example of just how pervasive the plug-in frameworkpattern is in Symbian OS is the original implementation of applicationsas plug-ins to the application and UI Framework rather than as more conventional executables.
(This architecture changes somewhat in SymbianOS v9, where applications are implemented as EXEs rather than DLLs,while retaining other characteristics of plug-ins.)In implementation terms, an ECom plug-in is implemented as a polymorphic DLL and a resource (RSC) file. The DLL entry point is a factoryfunction that instantiates the plug-in object. All system plug-ins are storedinto well-known locations, as required by the security model.The plug-in framework provides a standard and universal mechanismfor binding implementations (plug-ins) to interfaces (frameworks) at runTHE KEY DESIGN PATTERNS63time, together with the mechanisms for packaging multiple interface implementations into a single DLL (that is, loading multiple implementationsat once, to improve performance), plug-in registration and implementation versioning, discovery and loading including boot-time discoveryoptimizations to avoid run-time overhead, and cleanup after unloadingplug-ins. (A plug-in instance cannot destroy itself, because its destructorcode would be part of the code being removed from memory.) The framework also provides security-policy definition and policing mechanisms.The plug-in framework is implemented as a server, in effect a brokerbetween frameworks and conforming plug-ins, managing those plug-insas a resource to its framework clients.Microkernel ArchitectureSymbian OS has a microkernel architecture, which sets it apart fromoperating systems such as Microsoft Windows and Linux.14 In SymbianOS, core services that would be inside the kernel in a monolithic operating system are moved outside.
The pervasive use of the client–serverarchitecture, and the protection of system code from clients which follows from it, guarantees both the robustness and high availability of theseservices. The goal is a robust system that is also responsive and extensible;experience suggests that the design achieves it.Andrew Thoelke:The actual client–server architecture, the division into processes across theoperating system and the boundary of the kernel, means that the actualprivileged mode software is much smaller than in desktop operating systems.It’s very nearly theoretical microkernel, but not completely truly microkernelbecause device drivers all run kernel side, and a true microkernel would saythat device drivers should run user side, and who knows maybe we’ll get therein a few years time.
But all file system services, all higher level comms servicesincluding networking, and the windowing software for example, all run userside.If anything the new EKA2 kernel architecture goes beyond the microkernel design and encapsulates the most fundamental kernel primitiveswithin a true real-time nanokernel, supporting an extended kernel thatimplements the remaining Symbian OS kernel abstractions, but is equally14There are microkernel implementations of Unix, based on the Mach microkernel.Mac OS X is an example; it is built as a Berkeley Unix variant with a Mach microkerneland proprietary user interface layer. Other microkernel designs include QNX, which is anoperating system similar to Unix, but not Unix; Chorus, which is not just a microkernel butalso object-oriented and which, like Mach, is capable of hosting Unix; and iTron, which isan important mobile-phone operating system in Japan.64INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OScapable of supporting ‘personality’ layers to mimic the interface of anyother operating system.
But the essential elegance of the Symbian OSkernel design goes right back to its earliest days.Martin Tasker:The Symbian model is that you’re either a user thread or a kernel thread,and if you’re a user thread then either you’re an application thread, whichhas a session with the window server and interacts with the user, or you’re aserver thread which has no interaction with the user.
And if you’re a serverthread, well then you sit around waiting for client requests to happen andwhen they do you service them, and in fact the kernel has a server and it doesjust that. There are a couple of kernel calls which are handled by somethingknown as fast execs, which don’t involve the kernel server. But the designphilosophy of the kernel is to make those things very short and sweet and toput most of the work into the server. I think that’s a cool architecture. Someof it goes down to Colly Myers’s explainability requirement, that it takes morethan an average programmer to implement any of this stuff, but any averageprogrammer should be able to use it.The lineage of course can be traced back to the precursor Psionsystems.Andrew Thoelke:It owes its design very much to the heritage of Series 3.
Colly Myers took thatsame OS structure, that you’ve got a small amount of protected mode softwarethat can do everything, and that even all the file system and file servicesactually operate in a separate process from that and have less privileges, andthat you have a very tightly integrated client–server architecture that actuallybinds everything together. That is definitely quite different to what you see ina lot of other systems.Notwithstanding the move to the EKA2 kernel architecture, at a highlevel the lineage is still visibly present.Martin Tasker:The change from EKA1 to EKA2 is a hugely significant change. But at thesystem-design level, you know that change hasn’t actually radically altered thesystem design at all. It’s still either application processes or server processes,and that design was actually pioneered all the way back in SIBO, and it hasn’tchanged much since then, and the reason is: it’s a proven design.THE APPLICATION PERSPECTIVE653.6 The Application PerspectiveSymbian OS has been designed above all to be an application platform(although it might be argued that that has begun to change, and that in thelatest devices it has become primarily an engine for driving fast, mobiledata communications).
Applications have always been an essential partof the system. The early operating system shipped with a complete setof productivity and communications applications targeting connectedPDAs. Although Symbian OS no longer supplies a GUI and user-readyapplications but only common application engines, Symbian OS phonesnow ship with more built-in applications than ever before, suppliedeither with the licensee GUI or as extras provided by the phone vendoror network operator.Charles Davies:Symbian started off as an operating system plus an application suite.
We neverdesigned it as an operating system independently of the suite of applications.Just as importantly, both S60 and UIQ are also explicitly pitched asopen platforms for third-party applications and provide extensive supportfor developers including freely available SDKs, support forums and tools.From the beginning the approach to applications has been graphicsbased. Like much else, the approach has evolved and, in particular, it hasevolved as Symbian’s user interface strategy has evolved.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
