DOC PREVIEW
UNO CSCI 8530 - System Call Implementation Low-Level Input/Output Subsystem

This preview shows page 1-2 out of 6 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

11The Tempo Operating SystemPart 8System Call ImplementationLow-Level Input/Output Subsystem2Device DriversDevice drivers are the primary components of the I/O subsystem.Each device driver:is responsible for managing input/output on a single type of device at the lowest level by managing the device’s controlleris not (normally) called from user mode (usually can’tbe called from user mode)frequently presents a “normalized” interface to the kernel (this depends on the particular OS design)3Device Driver BasicsA device driver usually has two parts: the top and the bottom.The top part is trigger by a call from the OS, and manipulates data structures, returns results, and – when necessary – triggers the bottom part (“priming the pump”). The top part may block.The bottom part of the device driver is usually interrupt driven (and includes the interrupt handler). It handles direct low-level interaction with the device and awakens the top part when a request has been completed. The bottom part will never block.4Devices and Device ControllersThe distinction between devices and their controllers is sometimes blurredA serial port is usually a single chip (e.g. an 8250 or 16550)A modern (IDE or SCSI) disk has a built-in controllerA display has a monitor and a video “adapter” that usually has many componentsA common practice is to allow one controller to support multiple devices. For example, multiple old “ATA” style disks were connected to one controller.5Controllers and DevicesSystem BusCPU MemoryControllerIDE DiskControllerIDE DiskThe controller in this drive is inactive.Serial PortSerial Device (e.g. a modem)Keyboard (with 8042 chip)PPI: Programmable Peripheral InterfaceVideo Adapter Monitor6Buses: ISA, PCI, USB, AGPAlthough simple diagrams (as in the previous slide) show only one bus with everything connected to it, modern systems have many interface buses. For example:ISA (Industry Standard Architecture): found in older PCsPCI (Peripheral Component Interconnection): modern replacement for ISAPCI Express: an even more modern version of PCI!USB (Universal Serial Bus): frequently used to connect external devicesAGP (Accelerated Graphics Port): based on enhancement of PCI forvideo adapters27BridgesHow are all these buses interconnected in a computer system?Answer: with bridges!A bridge is essentially a device (chip) that maps signals between bus formats (synchronization, data, control, etc.)A common PC architecture has a “north” bridge between the host bus and the PCI, and DRAM (memory) buses; the “south” bridge connects the PCI bus to the ISA, USB, IDE, and AGP buses.But many different organizations are possible!8Host AdaptersSo what’s a host adapter (e.g. as used with IDE drives)?A host adapter (more completely called a host bus adapter is the hardware that connects a bus from one or more devices to a bus in the computer system.For example, the cables from IDE drives are a bus which is different from a PCI bus. The host adapter is a bridge-like device that connects the IDE drive bus to the PCI bus.There are even multiple kinds of IDE busses: parallel and serial, requiring different kinds of host adapters.SCSI is also another common disk drive bus type, and the SCSI adapter/host adapter/host bus adapter is used to connect SCSI drives (or more properly, a SCSI bus) to a host bus (like the PCI bus).9Device ClassesDevices are commonly separated into two classes for ease of organization:Block devices: those which have addressable blocks of data (e.g. disks, CDs, DVDs); device drivers must be given a block number, a read/write command, and a buffer in each requestCharacter devices: everything else; device drivers transfer only one or a few bytes at a time, but must still have a read/write command and know where to get/put the data.10“Normalized” Driver Interface (1)In most UNIX implementations each device in each class has two numbers:major: identifies the controller for all devices of the same type (i.e. all IDE disks will have the same major device number)minor: identifies an instance of the device (i.e. each individual IDE disk will have a unique minor device number)Two arrays of structures (bdevsw and cdevsw) are indexed by the major device number to locate entry points to device drivers.11“Normalized” Driver Interface (2)Block device driver entry points:d_open – open a deviced_close – close a deviced_strategy – read or write a blockd_ioctl – I/O actions other than read or writeCharacter device driver entry pointsd_open – open a deviced_close – close a deviced_read, d_write – read or write a blockd_ioctl – I/O actions other than read or write12Tempo’s Device DriversTempo doesn’t (yet) use a “normalized” device driver format.Each device driver is represented by a system call for the most common actions.Device-specific Tempo system calls:rdc – read next keyboard characterconout – write character to the displaydiskio – read/write a disk block and wait for completionasynchio –asynchronous disk I/O request (queue the requests and continue executing)313The keyboard device driverThe top part of the keyboard device driver is in the rdc system call; the bottom half is the interrupt handler.rdc’s basic data structures include:kbdata: array (one for each console) of circular queues; each queue has at most NKEYS entries, each entry containing one character code. frstkey is index of first unused character code.keysem: array of semaphores (one for each console) with count equal to number of entries in console’s kbdataarray.14rdc: pseudocodeDo a down on the console’s semaphore keysem[con] with the specified timeout.Return TIMEOUT if the down operation timed out.Copy kbdata[con][frstkey[con]] to result.Increment frstkey[con] modulo NKEYS.Return result.15Keyboard Interrupt Handling (1)Each key press or release generates an interrupt (0x21, IRQ 1)When a keyboard interrupt is handled:The PIC is reenabled to allow additional interruptsThe keyboard status register is read to clear interrupt requestThe keyboard data register is read and used as argument to kybdisr(the second-level interrupt handler)When kybdisr returns, continue at isr30i (normal system call return activity)16Keyboard Interrupt Handling (2)In kybdisr, the kbtoa function is called with the key code as an argument. It returns NOCHAR if no charactercode should be returned.If the code indicates a virtual console switch should happen, do it (by calling setvidpg) and


View Full Document

UNO CSCI 8530 - System Call Implementation Low-Level Input/Output Subsystem

Download System Call Implementation Low-Level Input/Output Subsystem
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view System Call Implementation Low-Level Input/Output Subsystem and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view System Call Implementation Low-Level Input/Output Subsystem 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?