Concepts with Symbian OS (779878), страница 44
Текст из файла (страница 44)
The operating system moves every print request to the spool andthe printing system polls the spool. This type of system is used for everydevice that cannot multiplex between concurrent requests. Tape drivesalso use spooling.Sometimes operating systems set up other ways of dealing with multiplerequests for the same device. Device reservation is a technique that isused, where an application asks the kernel for a device and waits untilit can have exclusive access.
In this method, polling is used to wait forthe device (just the condition spooling was designed to avoid). However,there are times when an application must have more direct control overa device and reservation ensures that the application can get this kind ofaccess.Errors happen often in the handling of devices.
Devices are not alwaysconnected in the tight, controlled fashion that other components of acomputer are connected. This means that data errors can creep intocommunication. Other factors, including bus overloading and controllerfailure, also cause errors. Errors in device communication are usuallyhandled by the kernel and signaled to applications making system calls.Errors usually result in system-call failure, indicated, in same way, tothe caller by the return value of the system call.
Some systems return avalue of ‘0’ if a system call succeeds and ‘1’ if it fails; other systems setexternal variables (e.g., errno in Unix) to reflect the error status of acommunication operation. Devices often maintain detailed logs of errorsand the reasons for them; kernels can access these logs by using furthersystem calls.The kernel often keeps a lot of data on the state of devices. Datastructures used in the kernel often form a set of tables that maintain stateand access information.
These tables require a large amount of memoryto maintain and much of the memory consumed by the kernel as it isrunning is filled with data tables keeping track of devices.TimersThere are many types of devices used with operating systems. Clocksand timers are devices – although they are not considered as such. 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.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
