Device DriversI/O and Operating SystemsI/O ModelsThe Unix ModelThe Windows ModelNetworkingI/O ModelUnix I/OBack to UnixMajor Device NumbersMinor Device NumbersDevice-Specific SemanticsDevice Driver InterfaceBlock DevicesDisk SchedulingDisk SchedulingConflicting DemandsTwo Not So Good AnswersElevator AlgorithmOrder of OperationsRotational DelayGraphicsA Simple ModelToo Slow!Hardware AssistProgramming InterfaceNetworkingNetwork DevicesNetwork OutputNetwork InputThe Network StackPhysical I/OReal I/O IssuesThe Linux Printer DriverInterrupt LoadsProgrammed I/O and DMAMemory Access IssuesVirtual MemoryScatter/Gather I/ODirect I/OAddress Space SizeDisk Block Address SpaceDevice Drivers 1 / 36I/O and Operating Systems■ As previously discussed, all I/O must go through the operating system■ A typical system has (or could have) many different types of devices■ What kind of software talks to these devices?■ What is the interface between the OS and that software?■ What is the interface to application programs?■ Are there any hardware constraints?1 / 36I/O Models■ All operating systems impose t ight controls on disk access, because the OSitself needs to access the disk and control file storage■ Operating systems frequently provide high-level access to common types ofdevices: serial ports, printers, tapes, etc.■ Some operating systems p ermit user-specified complex I/O to some devices(tapes, displays)■ The more “normal” an I/O device is, the more likely it is to be accessed by astandard model■ Try for an I/O model that lets most applications be device-independent2 / 361The Unix Model■ Two categories, block devices and character devices■ File systems live on top of block devices■ Block devices are designed for “give me N blocks starting at block number M ”■ Almost never used directly by the application programmer■ Character devices — everything else — return a series of unstructured bytes■ Provides a high degree of device independence — for most applications. . .3 / 36The Windows Model■ More oriented towards bit maps■ Screens are bitmaps■ Printers are bitmaps■ Disks? Disks use the same block model as in Unix4 / 362Networking■ Network devices are completely different■ They’re neither block nor character-oriented■ They’re used very differently by the OS5 / 36I/O Model■ Character devices■ Block device s■ Bitmaps■ Networks6 / 363Unix I/O 7 / 36Back to Unix■ All devices have filenames:$ ls --time-style "+" -Ggl \/dev/sda1 /dev/pts/6crw--w---- 1 136, 6 /dev/pts/6brw-rw---- 1 8, 1 /dev/sda1■ The “c” indicates a character I/O devices; the “b” indicates a block d evice■ The “136” and the “8” are major device numbers■ The “6” and the “1” are minor device numbers■ Device files are created with mknod7 / 36Major Device Numbers■ Major device numbers indicate the device type. More specifically, they indicatethe device driver to be used■ Device driver numbering is very system-specific■ Block and character device numbers are separate namespaces8 / 364Minor Device Numbers■ Minor device numbers indicate the unit: which disk drive, whic h serial port,etc.■ In some cases, the minor device number has other flags encoded in the number■ Example: on Linux, the minor device for a SCSI disk is16 × drivenum + partition9 / 36Device-Specific Semantics■ Not all devices are alike■ Some provision has to be made for device-specific semantics■ Example: skip a “file” on a tape■ Example: handle special characters from terminals: backspace, ˆC, etc.■ Certain operations are handled by ioctl calls■ Tty processing is handled by a “line discipline” that is invoked by all tty-likedevices10 / 365Device Driver Interface■ All devices have certain standard entry points: open, close, read, write, ioctl,etc.■ Devices implement Unix semantics as best they can■ Device-specific restrictions may, of course, be honored11 / 36Block Devices■ Also have a standardized interface, but it’s quite different■ Again, primary function is read/write blocks on disk■ Integrated with buffer cache and memory subsystem■ Accessed primarily through the file system■ (Exception: some high-end database systems)■ Still need device-specific commands (see hdparm command on Linux)12 / 366Disk Scheduling 13 / 36Disk Scheduling■ Disk seeks are slow■ Rotational delay takes time, too■ Disk I/O driver must optimize throughput13 / 36Conflicting Demands■ Fairness: do I/O operations in order of arrival■ Efficiency: don’t waste a lot of time seeking■ Promptness: don’t delay some requests indefinitely14 / 367Two Not So Good Answers■ First come, first served — very inefficient■ Shortest seek first — unfair to requests at the ends of the disk; vulnerable toindefinite overtaking15 / 36Elevator Algorithm■ Move the arm in one direction at a time■ Implication: must sort I/O requests by sector■ First write in ascending sector order, then write in descending sector order■ Still has fairness issues — what if you get a lot of requests close to the currentpoint? (Remember that file systems try to allocate blocks locally)16 / 368Order of Operations■ Recall that file system safey semantics demand that some blocks be written ina particular orde r■ This causes a discontinuity in the queue■ Besides, do you really know the disk geometry?■ The controller may implement its own version of this algorithm; the driver hasto send it enough simultaneous requests that it can optimize17 / 36Rotational Delay■ Rotations take a while, too■ Scatter blocks around the disk to optimize for reading consecutive sectors■ Can be done at several layers: file system, device driver, controller■ Comments about disk geometry still apply18 / 369Graphics 19 / 36A Simple Model■ The screen is just an array of pixels■ Map each pixel to some set of bits or bytes; have software calculate the valueof each one■ Tell the screen the address of the array19 / 36Too Slow!■ That algorithm couldn’t keep up with even modest graphics dem ands■ It wouldn’t come close to being fast enough for games■ Must have hardware assist20 / 3610Hardware Assist■ User programs work in higher-level terms: characters, polygons, filled orshaded areas, curors, scrolling, etc.■ Each graphics controller is programmed — some use a standardized language,some a proprietary one■ Graphics processors are quite sophisticated (though