Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 100
Текст из файла (страница 100)
The framework will do this for you, but only after the clienthas returned from the AbortNow() call. This means that this function should do the minimum amount of work and return as quickly aspossible.When WSERV tells the client that it needs to abort its DSA, it waitsto receive the acknowledgment from the client that it has done so.However, it doesn’t wait for ever, since the client may have entered somelong running calculation or even an infinite loop. So WSERV also waits ona timer.
If the timer expires before the client acknowledges, then WSERVcontinues. If, later on, WSERV gets notification from the client that it hasaborted the DSA, then WSERV will invalidate the region in which theDSA was taking place, just in case there had been a conflict between theDSA and another client.Here are a few other restrictions on what you can do in the AbortNow() function. You can’t call WSERV, because then a temporarydeadlock will occur. This is because WSERV is waiting to receive theclient’s acknowledgment that it has aborted, and so will not be able toservice the call.
Also, since you are not allowed to make calls to WSERVin the AbortNow() function, you can’t restart the DSA in this function.This is where the other callback is needed, the Restart() function.The DSA framework has set up an active object to call this functionand it should be called during the next active object run in that thread.The purpose of this function is to give the client the earliest possibleopportunity to restart the DSA with the new area.There is one final restriction on clients performing DSA. This is that,while the DSA is in operation, the client should not make any call toWSERV that will affect the visible area of the window in which the DSAis taking place.
Again, if this were to happen, it will cause temporarydeadlock – since the client will be waiting for WSERV to make therequested window rearrangement, and WSERV will be waiting for theclient to acknowledge that the DSA has aborted.PLATFORM SECURITY IN WSERV11.12473Platform security in WSERV11.12.1 WSERV’s command bufferIn Symbian OS, platform security is enforced on client server boundaries (for more on this, see Chapter 8, Platform Security ). WSERV is noexception to this.
However, because of WSERV’s command buffer, theimplementation differs from that of other servers. Other servers receivea single command sent by the client with a single call to either RSessionBase::Send() or the RSessionBase::SendReceive(), and thekernel can be instructed which commands (specified with the aFunction parameter) need which security capabilities. WSERV has one maincommand which is called in this function:TInt RWsSession::DoFlush(const TIpcArgs& aIpcArgs){return SendReceive(EWservMessCommandBuffer,aIpcArgs);}This command tells the server that there is a command buffer waitingfor it.
WSERV places many individual commands into this commandbuffer, saying which server object to send the command to, whichcommand or function to execute on that object and any parameters forthat command. Each of these commands potentially needs to be policedfor the capabilities of the client. Thus we have to do the policing in theserver code that executes the commands.On the server side, each command buffer is unpacked in the functionCWsClient::CommandBufL(), which passes the commands onto thisfunctions:virtual void CWsObject::CommandL(TInt aOpcode,const TAny *aCmdData)=0;or at least the version of this function in the respective derived class.This means that we must do the policing in the respective CommandL()function.11.12.2 What things does WSERV police?WSERV checks for three different capabilities – SwEvent, WriteDeviceData and PowerMgmt.
The details of which APIs police whichcapabilities are given in any Symbian OS SDK, so there is no need forme to reiterate here. Instead I will describe the type of API that is policedwith each of these capabilities, and the motivation for this policing.474THE WINDOW SERVERThere are various client-side functions that can be used to send anevent to a WSERV client.
Examples are RWsSession::SendEventToWindowGroup and RWsSession::SimulateRawEvent. These functions are policed by SwEvent to spot rogue applications that generateevents designed to break other applications.WSERV has many global settings that can be changed by any client.These include keyboard repeat rate, system pointer cursor list, defaultfading parameters and current screen size mode. Since these settingsaffect all clients of WSERV, we must intervene if rogue applications try toset them to bad values.
So we police them using WriteDeviceData.WSERV has two APIs that are concerned with switching off the mobilephone. One of these is RWsSession::RequestOffEvents(), whichan application calls if it wants to receive off events. Only one applicationcan receive these events, as it is then in charge of making sure that thesystem is ready to be turned off (for example, ensuring all data is saved)and then calling the kernel to power down the device. The other function,RWsSession::PrepareForSwitchOff() is called to tell WSERV tostop its timer so that the processor can be switched off – if the timercontinued to run it would wake the processor up again.
These APIs areboth protected by PowerMgmt.11.13SummaryWSERV has a major role to play in all aspects of the UI of any device.It has rich APIs for dealing with all aspects of event handling, windowmanagement and drawing window content, as well as code for managingthe different types of event and holding them until clients are ready toreceive them.
WSERV provides a variety of ways of drawing to the screen,including anim DLLs, redraw windows and direct screen access.In the next chapter, I shall discuss device drivers and extensions.12Device Drivers and Extensionsby Stefan Williamswith Tony LofthouseIt is pitch dark.
You are likely to be eaten by a grue.Zork IIn the previous chapters of this book, I have concentrated on the fundamental concepts and services that make up the EKA2 kernel, and haveintroduced some of the fundamental hardware resources that the kernelrequires, such as the interrupt controller provided in the ASSP class toprovide the access to the millisecond timer interrupt.The aim of this chapter is to explain how hardware resources areprovided to the system as a whole. For example, the file server requiresaccess to a variety of media storage devices, while the window serverrequires access to the LCD display and touch screen.
This chapter willstudy the frameworks that exist to allow us to provide support for suchdevices.In particular, I will cover:• The device driver architecture – an overview of device drivers andtheir place in Symbian OS• Kernel extensions – these are key modules required by the kernel atboot time, and this section explains how they are created and usedby Symbian OS• The HAL – this section explains how the hardware abstraction layeris used by extensions and device drivers to provide standard devicespecific interfaces to user-side code• Accessing user memory safely – this section explains how to ensurethat you are writing safe kernel-side code, fundamental to the stabilityof the system476DEVICE DRIVERS AND EXTENSIONS• Device drivers – the user’s interface to hardware and peripherals.
Thissection explains the EKA2 device driver model• Differences between EKA1 and EKA2 – how the device driver modelchanged in the EKA2 release of the kernel.12.1Device drivers and extensions in Symbian OSIn Chapter 1, Introducing EKA2, I introduced the various hardware andsoftware components that make up a typical Symbian OS device, andshowed the modular architecture as in Figure 12.1.EWSRVEFILE(window server)(file server)ESTARTEUSERHAL(user library)privilege userboundary kernelDEVICEDRIVEREKERN(kernel)memorymodelnanokernelEXTENSIONLDDPlatformIndepentLayerPDDPlatformSpecificLayerASSPRTOSPERSONALITYLAYER(EXTENSION)variantphysical softwareboundary hardwareMMUCPUPeripheralsPic& timerBSPboundaryFigure 12.1 Symbian OS overview12.1.1 What is a device driver?The role of a device driver is to give a user-side application access toperipheral resources without exposing the operation of the underlyinghardware, and in such a manner that new classes of devices may beintroduced without modification of that user-side code.Also, since access to hardware is usually restricted to supervisor-modecode, the device driver (which runs kernel-side) is the means of access tothese resources for user-mode client threads.Device drivers are dynamically loaded kernel DLLs that are loadedinto the kernel process after the kernel has booted (either by user request,DEVICE DRIVERS AND EXTENSIONS IN SYMBIAN OS477or by another layer of the OS).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
