13.07.2015 Views

iAPX 286 Operating System Writers Guide 1983

iAPX 286 Operating System Writers Guide 1983

iAPX 286 Operating System Writers Guide 1983

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.

INPUT /OUTPUTtask the I/0 procedures run in. The I/O interface procedures (READ, WRITE, etc.) must have DPLequal to that of the global I/0 data and therefore must have call gates at the privilege level of applicationprocedures (PL 3). If these call gates reside in the LDTs of application tasks, then I/0 interfaceprocedures can be shared by (but limited to) those tasks that need them. The call gates can also residein the GDT, where all tasks can access them. In either case the interface procedures run in the callingtask.The possibilities for running device drivers in parallel with the calling task suggests that they be separatetasks. Such a separation also serves to protect applications and device drivers from one another, adefinite advantage because inherent complexity and frequency of change tend to place device driversamong the least reliable of operating system functions. The I/0 interface procedures have the responsibilityfor managing the details of communication between the calling task and the device drivers.You can implement a sophisticated device driver such as that illustrated in figure 8-3 as two cooperatingtasks: one scheduled by interrupts via a task gate in the IDT, and the other scheduled by I/Orequests via an operating-system mailbox facility.It is possible to implement device drivers as interrupt procedures that run within applications tasks.Such a structure is advantageous in these cases:• Efficiency of I/0 is an overriding goal.• Interrupts may arrive when a driver is busy.The lack of protection inherent in such a structure becomes apparent, however, when you consider thatthe driver procedure that fields an I/O-complete interrupt may run as part of a task completely unrelatedto the task that originally requested the I/O operation, and must run at PL O.Viewing the possible implementations of buffers from the perspective of the <strong>iAPX</strong> <strong>286</strong> architecture,the most pertinent consideration is whether a segment contains just one buffer or several buffers. Anapproach that uses one segment per buffer has several advantages:• The protection mechanism of the <strong>iAPX</strong> <strong>286</strong> (working as it does on segment descriptors) focuses oneach buffer individually.• The selector of a buffer segment serves as a convenient buffer identifier, fitting easily into thealiasing and mailbox schemes outlined in Chapter 5.You can avoid the potential GDT congestion that may result from having one segment (and thereforeat least one segment descriptor) per buffer by storing buffer descriptors in LDTs.When tasks share buffers (as between an application task and one or more device-driver tasks), youhave a choice between• Leaving the buffer at all times within the address spaces of all the sharing tasks• Transferring the buffer from the address space of one task into that of anotherThe mailbox scheme outlined in Chapter 5 easily accomplishes the latter approach. This scheme hasthe advantage that the application task cannot use the buffer at the same time as I/O is in progress.The "usage privilege level" (UPL), if set to IOPL, provides additional protection by limiting mailboxaccess to I/O procedures. The application's requirements for I/O efficiency may, however, precludeuse of mailboxes for this purpose.8-7 121960-001

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

Saved successfully!

Ooh no, something went wrong!