Smartphone Operating System (779883), страница 45
Текст из файла (страница 45)
Mostcomputers have hardware clocks and timers available for applicationsto use and they are typically used and manipulated in the same way as208INPUT AND OUTPUTexternal devices. These devices are very useful and provide three basicfunctions:• the current time of day• elapsed time• triggers or alarms that cause interrupts to fire when they expire.The operating system and applications use these capabilities extensively.Kernels and applications depend on interval timers for their operations.Interval timers can be set and interrupts are triggered when time runsout.
Timers can be programmed to automatically reset themselves oncethey expire and this capability is used to generate periodic interrupts.The system scheduler uses mechanisms such as these to do contextswitching. Timers are used to signal periodic flushing of data caches.Device time-outs are managed by the kernel using interval timers.Usually a computer system has only one hardware clock, but softwarevirtual clocks allow an operating system to use many different timers andprovide them to applications. To implement virtual clocks, the kernelmaintains a sorted list of requested timer events and continually resets thetimer for the next queued event requested. When a timer event occurs,the kernel resets the timer for the next earliest time.Sometimes, applications – or the kernel – need to keep track of timein very fine units.
Microseconds are very important in the maintenance ofsome applications. Computer clocks do not usually keep time in very fineincrements, often providing only coarse-grained resolution. It is typicalfor hardware clocks to provide only up to 60 ticks per second. Sometimeshigher-resolution hardware clocks are provided, but they are availableonly for sampling; they are not integrated into the timer/interrupt systemas the standard system clock.Blocking and Nonblocking I/OKernels deal with the speed disparity between CPUs and devices in manyways (we have already discussed several).
One way is to provide a choiceto the user: should access to a device block while data is transferred orremain unblocked and asynchronous?A blocking system call suspends the process making the call until thesystem call can complete. Completing the system call means retrievingor writing the appropriate amount of data from or to the device beingI/O IN SYMBIAN OS209used. Blocking system calls remove a process from the running or readyqueues and place it into the waiting queue: the process is blocked whilewaiting for a device to complete an operation. Once the system callhas completed, the process is returned to the running or ready queue(depending on the semantics of the operating system) and executionresumes.
Most operating systems use blocking I/O calls for applications;it is easier to understand and deal with blocking application code.A nonblocking system call is implemented by checking the status ofthe devices referenced in the call. If the device is ready to perform theoperation, the call executes that operation and returns. If the device isnot ready, the call returns immediately with an error code.Another version of a nonblocking system call is an asynchronous call.The call results in a request made to the device being used, but returnsimmediately. When the requested operation is complete, the process issomehow notified.
This notification could take the form of a softwareinterrupt or event or could result in the operating system calling a specificfunction defined within the process.Blocking calls are typical when dealing with reading and writingfrom files. The delays are not burdensome and the semantics of readingand writing make more sense if blocking I/O is used. On the otherhand, working with user interface devices – such as a touch screen or amouse – is most effective with nonblocking I/O calls. Notifying a processwhen the screen is touched means the system can work on other thingsand deal with user input only when that input is ready.Multithreaded applications are most effective with I/O calls.
Whilethe system waits for I/O to happen, other parts of the application cancontinue executing.9.4 I/O in Symbian OSAs an example of I/O architecture, let’s consider the way Symbian OShandles input and output. The goal here is not to give you a completetour through the I/O structure of Symbian OS, but rather to give examplesof the discussion above.Device DriversIn Symbian OS, device drivers execute as kernel-privileged code and giveuser code access to system-protected resources.
As we discussed, devicedrivers represent software access to hardware.210INPUT AND OUTPUTA device driver in Symbian is split into two levels of drivers: a logicaldevice driver (LDD) and a physical device driver (PDD). The LDDpresents an interface to the upper layers of software while the PDDinteracts directly with the hardware. In this model, the LDD can remainconsistent over a specific class of devices, while the PDD changes foreach device. Sometimes, if the hardware is fairly standard or common,Symbian OS also supplies a PDD.Consider an example of a serial device. Symbian OS defines a genericserial LDD (ECOMM.LDD) that defines the user side API for accessing theserial device.
The LDD represents an interface to the PDD, which providesthe interface to serial devices. The PDD implements buffering and theflow control mechanisms necessary to help regulate the differences inspeed between the CPU and serial devices. A single LDD – the userinterface – can connect to any of the PDDs that might be used to runserial devices.LDDs and PDDs can be dynamically loaded by user programs if theyare not already existing in memory. Programming facilities are providedto check to see if loading is necessary.Kernel ExtensionsKernel extensions are device drivers that are loaded by Symbian OS atboot time. Because they are loaded at boot time, they are special casesthat need to be treated differently from normal device drivers.Kernel extensions are built into the boot procedure.
These specialdevice drivers are loaded and started after the scheduler starts. Theyimplement functions that are crucial to operating systems: DMA services,LCD management, bus control to peripheral devices (e.g., the USB bus).These are provided for two reasons. First, it matches the object-orienteddesign abstractions we have come to see as characteristic of microkerneldesign. Secondly, it allows the separate platforms that Symbian OS runson to run specialized device drivers that enable the hardware for eachplatform without recompiling the kernel.Hardware Abstraction LayerSymbian OS uses abstraction in many ways; the hardware-abstractionlayer (HAL) is a great example of this.
The HAL is a set of variables andfunctions that access system configuration and attributes.The API consists of a series of C++ enumerations and handler functionsthat manage the group attributes. Some HAL groups correspond to specificI/O IN SYMBIAN OS211hardware devices, such as displays or keyboards, while other groupsaccess general platform parameters, such as media-driver informationand timers.Direct-Memory AccessDevice drivers frequently make use of DMA and Symbian OS supportsthe use of DMA hardware.
DMA hardware consists of a controllerthat controls a set of DMA channels. Each channel provides a singledirection of communication between memory and a device. Using theDMA hardware, bidirectional transmission of data requires two DMAchannels. At least one pair of DMA channels is dedicated to the screenLCD controller. In addition, most platforms provide a certain numberof general DMA channels. Once data has been transferred, a systeminterrupt is triggered.The DMA service provided by DMA hardware is used by the PDD – thepart of the device driver that interfaces with the hardware.
Between thePDD and the DMA controller, Symbian OS implements two layers ofsoftware. There is the software DMA layer and a kernel extension thatinterfaces with the DMA hardware. The DMA layer is itself split into aplatform-independent layer and a platform-dependent layer. As a kernelextension, the DMA layer is one of the first device drivers to be startedby the kernel during the boot procedure.Support for DMA is complicated for a special reason. Symbian OSsupports many different hardware configurations and no single DMAconfiguration can be assumed. The interface to the DMA hardware is standardized across platforms, and is supplied in the platform-independentlayer.
The platform-dependent layer and the kernel extension are suppliedby the manufacturer, thus treating the DMA hardware in the same waythat Symbian OS treats any other device: with a device driver in LDDand PDD components. Since the DMA hardware is viewed as a devicein its own right, this way of implementing support makes sense becauseit parallels the way Symbian OS supports all devices.Storage MediaMedia drivers are a special form of PDD that are used exclusively bythe file server to implement access to storage media devices. Becausesmartphones can contain both fixed and removable media, the mediadrivers must recognize and support a variety of storage. Symbian OS212INPUT AND OUTPUTsupport for storage media includes a standard LDD and an interface APIfor users.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
