Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 101
Текст из файла (страница 101)
They may be execute-in-place (XIP) orRAM loaded, and like other kernel-side code may use writeable staticdata. (For more details on the differences between XIP and RAM loadedmodules, please refer to Chapter 10, The Loader.)Extensions are merely special device drivers that are loaded automatically at kernel boot. I shall say more about them later.12.1.2 Device driver architectureThe Symbian OS device driver model uses two types of kernel DLL – thelogical device driver (LDD) and the physical device driver (PDD). SeeFigure 12.2.
This flexible arrangement provides a level of abstraction thatassists in porting between platforms and in adding new implementationsof device drivers without impacting or modifying common code and APIs.12.1.2.1 The logical device driverThe LDD contains functionality that is common to a specific classof devices. User-side code communicates with an LDD via a simpleinterface class, derived from RBusLogicalChannel, which presents aUser codeinteractionDriverApiClassRBusLogicalChanneluserkernelLDDPDDsoftwarehardwarehardwaredeviceFigure 12.2Overview of the device driver architecture478DEVICE DRIVERS AND EXTENSIONSwell-defined driver-specific API.
We use the term ‘‘channel’’ to refer to asingle connection between a user-side client and the kernel-side driver.Since hardware interfaces vary across platforms, an LDD is usuallydesigned to perform generic functionality, using a PDD to implement thedevice-specific code.LDDs are dynamically loaded from user-side code but may performsome initialization at boot time if they are configured to do so. I’ll explainhow this is achieved when I discuss the use of extensions.Symbian provides standard LDDs for a range of peripheral types (suchas media drivers, the USB controller and serial communications devices).However, phone manufacturers will often develop their own interfacesfor custom hardware.12.1.2.2 The physical device driverThe physical device driver is an optional component, which containsfunctionality that is specific to a particular member of the class of devicessupported by the LDD.
The PDD typically controls a particular peripheralon behalf of its LDD, and obviously it will contain device-specific code.The PDD communicates only with its corresponding LDD, using an APIdefined by the logical channel, so it may not be accessed directly froma user-side application. The role of the PDD is to communicate with thevariant, an extension, or the hardware itself, on behalf of the LDD.To illustrate this, consider the example of a serial communicationsdevice. The generic serial communications LDD (ECOMM.LDD) definesthe user-side API and the associated kernel-side PDD interface for allserial devices.
It also provides buffering and flow control functions thatare common to all types of UART. On a particular hardware platform,this LDD will be accompanied by one or more PDDs that support thedifferent types of UART present in the system. (A single PDD may supportmore than one device of the same type; separate PDDs are only requiredfor devices with different programming interfaces.) This is demonstratedin the following .oby file, which specifies that the ROM should contain:1.The generic serial communications LDD (ECOMM.LDD)2.Two device-specific PDDs (EUART1.PDD, EUART2.PDD).device[VARID] = \Epoc32\Release\Arm4\Urel\16550.PDD\System\Bin\EUART1.PDDdevice[VARID] = \Epoc32\Release\Arm4\Urel_SSI.PDD\System\Bin\EUART2.PDDdevice[VARID] = \Epoc32\Release\Arm4\Urel\ECOMM.LDD\System\Bin\ECOMM.LDDBoth PDDs interface with the generic LDD, which presents a commoninterface to the hardware to any user of the communications device.DEVICE DRIVERS AND EXTENSIONS IN SYMBIAN OS479Further examples include:DriverLDDAssociated PDDSound DriverESOUNDESDRVEthernet DriverENETETHERNETLocal Media Sub-systemELOCDMEDNANDMEDLFSMEDMMCSimilarly to LDDs, PDDs may be configured to perform initializationat boot time.12.1.3 Kernel extensionsFundamentally, kernel extensions are just device drivers that are loadedat kernel boot.
However, because of this, their use cases are somewhatspecialized.By the time the kernel is ready to start the scheduler, it requiresresources that are not strictly defined by the CPU architecture. These areprovided by the variant and ASSP extensions, which I have discussedin Chapter 1, Introducing EKA2. These extensions are specific to theparticular platform that Symbian OS is running on, and permit the phonemanufacturer to port the OS without re-compiling the kernel itself.After initializing the variant and ASSP extensions, the kernel continuesto boot until it finally starts the scheduler and enters the supervisor thread,which initializes all remaining kernel extensions.
At this point, all kernelservices (scheduling, memory management, object creation, timers) andbasic peripheral resources (interrupt controller and other ASSP/variantfunctionality) are available for use.Extensions loaded at this late stage are not critical to the operation ofthe kernel itself, but are typically used to perform early initialization ofhardware components and to provide permanently available services fordevices such as the LCD, DMA, I2C and peripheral bus controllers.The final kernel extension to be initialized is the EXSTART extension,which is responsible for loading the file server. The file server is responsible for bringing up the rest of the OS.
(If you want to find out more aboutsystem boot, turn to Chapter 16, Boot Processes.)In Figure 12.1, the extension consists of two components – theplatform-independent layer (PIL) and platform-specific layer (PSL). Theseare analogous to the LDD/PDD layering for device drivers that I discussed480DEVICE DRIVERS AND EXTENSIONSearlier. To make porting an extension to a new hardware platform easier,the PIL is generally responsible for providing functionality commonto versions of the extension (such as state machines and so on) anddefining the exported API, with the PSL taking on the responsibility ofcommunicating directly with the hardware.
Therefore, when porting to anew hardware platform only the PSL should require modification.Note: Some device drivers use the same concept and split the PDD intoplatform-independent and platform-specific layers. One such example isthe local media sub-system – this consists of a generic LDD interfacesuitable for all media drivers, and a PDD interface which is furtherdivided to handle common device interfaces such as ATA/PCMCIA,NAND or NOR Flash.12.1.4 Shared library DLLsThe most basic way to offer peripheral resources to other componentswithin the kernel (not to user-mode applications) is to develop a simplekernel DLL (by specifying a targettype of KDLL in the extension’sMMP file).
Kernel DLLs can provide a static interface through which otherkernel components gain access to the hardware:class MyKextIf{public:IMPORT_C static TUint32 GetStatus();IMPORT_C static void SetStatus(TUint32 aVal);};EXPORT_C TUint MyKextIf::GetStatus(){ return *(volatile TUint32 *)(KHwBaseReg); }EXPORT_C void MyKextIf::SetStatus(TUint aVal){ *(volatile TUint32 *)(KHwBaseReg) = aVal; }Of course, a shared library DLL may offer any functionality that maybe of use from other components within the kernel (not only accessto peripheral resources).
However, a kernel DLL is not defined as anextension so is not initialized by the kernel at boot time, so can’t makeuse of writeable static data. Using a kernel extension opens up theopportunity to provide a much richer interface.12.1.5 Static data initializationKernel-side DLLs, such as device drivers and extensions, are only everloaded and used by a single process, the kernel itself. Hence, they onlyneed one copy of static data (of course, if several threads within the sameprocess require access to this data, the usual care must be taken to avoidsynchronization issues).DEVICE DRIVERS AND EXTENSIONS IN SYMBIAN OS481Writeable static data for ROM-resident kernel-mode DLLs (that is, thosedeclared in the rombuild.oby file with the keywords variant, deviceor extension) is appended to the kernel’s static data.
Initializationof variant and extension data occurs at kernel boot time, whileinitialization of device data occurs at device driver load time. Writeablestatic data for RAM-resident device drivers is placed in an extra kerneldata chunk which is mapped with supervisor-only access.It is important to note that since the kernel itself loads extensions,they are never unloaded.
Therefore, the destructors for any globallyconstructed objects will never be called.12.1.6Entry pointsEach type of kernel DLL has a unique set of characteristics that definehow and when the kernel loads them during boot; these are defined bythe form of the DLL’s entry point. Symbian provides three different entrypoints, in three different libraries, and you select one by choosing whichof these libraries to link against.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
