13.07.2015 Views

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

176 Transput Chapter 5Input buffers have the same declaration as output buffers. The kernel is expectedto fill these buffers ahead of the process. As soon as the process has finished using thedata in a buffer, it tells the device driver by performing the following service call:FreeBuffer(buffer address). This call resets the Busy flag to false and informsthe device driver that the buffer is ready to be filled with new data. (Where thedata come from is determined by a previous call to Read.)Buffer pools allow the programmer to tailor the number and size of buffers to the application.The process sets up the buffer pools by a service call:CreatePool(device descriptor, buffer length, number of buffers, direction).This call creates a buffer pool for the given device. The direction specifieswhether these are input or output buffers. Space may be created in a new segmentor as a new region at the end of virtual store. This call might have the side effectof making transput asynchronous.The advantage of the buffer-pool method is that programs that require more buffers forefficiency do not compete for buffers with other programs: The buffers are entirelywithin the address space of the process, not in a common pool in the kernel. Copying isnever necessary between kernel and user buffers because the size of the data area of abuffer is exactly the correct size for the device. However, the programmer now has theresponsibility to pack data into the fixed-size buffers and to handle the asynchronousnature of transput. In addition, it is often a matter of guesswork to decide how manybuffers are enough.A third alternative places even more responsibility in the hands of the programmer:The process executes channel programs instead of transput service calls. To perform aread operation, for example, the program builds a channel program of whatever complexityis desired and submits the following service call:StartTransput(address of channel program). This call starts the channel program.It returns a descriptor that can be used in the Wait or Handle calls.The channel program could be complex enough to rewind a tape and then copy the contentsof several non-consecutive disk tracks onto that tape. During the execution of thechannel program, the process could be occupied in other work. This alternative is attractivebecause of the efficiency it permits in performing complex transput-bound operations.However, it requires programmers to be experts at channel programs or to rely onlibrary packages that create simpler environments.Channel programs executed by the process are a real headache for the operatingsystemimplementor. Because typical channels do not have access to the addressmappinghardware, they expect all main-store addresses to be physical addresses. Theoperating system must therefore translate all the main-store addresses in the channel program.It must also tie the channel program down. Regions that are contiguous in virtualspace may be scattered in physical space, so single commands in the channel programmay have to be split into several subcommands.In some cases splitting is not possible. For example, a disk block usually must beread into a physically contiguous region of main store. If the channel program specifies avirtual region that is not physically contiguous, the operating system must either declare

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!