1. OPERATING SYSTEMS DESIGN AND IMPLEMENTATION Third Edition ANDREW S
OPERATING SYSTEMS DESIGN AND IMPLEMENTATION Third Edition ANDREW S. TANENBAUM ALBERT S. WOODHULL Chapter 3 Input/Output
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 1

2. I/O Overview Types of I/O devices and speeds
Device controllers and I/O strategies
Memory-mapped I/O, DMA
I/O Software Organization
Device-dependent and device-independent S/W
Resource Access and Management
Deadlocks and deadlock handling
Device Drivers in Minix3
Mass Storage Devices
Disk characteristics, scheduling
Terminals
Character-oriented, bit-oriented displays
Keyboard input handling, scan codes, keymaps, control sequences
Mouse input
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 2

3. I/O Overview Types of I/O devices and speeds
Device controllers and I/O strategies
Memory-mapped I/O, DMA
I/O Software Organization
Device-dependent and device-independent S/W
Resource Access and Management
Deadlocks and deadlock handling
Device Drivers in Minix3
Mass Storage Devices
Disk characteristics, scheduling
Terminals
Character-oriented, bit-oriented displays
Keyboard input handling, scan codes, keymaps, control sequences
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 3

4. Figure 3-1. Some typical device, network, and bus data rates.
I/O Devices
IBM 1402 punch card reader:
800 cards/minute
80 characters/card
1 byte/column (EBCDIC)
= 64,000 bytes/minute
= 1 KB/sec
IBM 2400 high density,
high speed 9-track tape drive:
200 in/sec
1600 bits/in/track
= 320 KB/sec
Figure 3-1. Some typical device, network, and bus data rates.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 4

5. I/O Overview Types of I/O devices and speeds
Device controllers and I/O strategies
Memory-mapped I/O, DMA
I/O Software Organization
Device-dependent and device-independent S/W
Resource Access and Management
Deadlocks and deadlock handling
Device Drivers in Minix3
Mass Storage Devices
Disk characteristics, scheduling
Terminals
Character-oriented, bit-oriented displays
Keyboard input handling, scan codes, keymaps, control sequences
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 5

6. Device Controllers
Figure 3-2. A model for connecting the CPU, memory, controllers, and I/O devices.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 6

7. I/O Strategies CPU – managed I/O Co-processor – managed I/O
CPU is directly involved in I/O transfers
Co-processor – managed I/O
CPU hands off I/O transfer to co-processor(s)
Port-mapped I/O
Special address space/instructions for I/O ports (e.g., PDP-8)
May or may not be CPU-controlled
Channel I/O
Special address space/instructions for channels (e.g., IBM-360)
Co-processor manages channel(s)
Memory-mapped I/O
I/O controllers are accessed in same address space as memory
I/O memory acts funny
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 7

8. Typical Intel Chipset Layout (Wiki Images)
Frontside/Backside buses
Frontside bus
Northbridge
Mem Ctrlr Hub
Internal bus
Southbridge
I/O Ctrlr Hub
PCI bus
LPC bus
(images from Wiki Images)
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 8

9. Memory-Mapped I/O
Figure 3-3. (a) Separate I/O and memory space. (b) Memory-mapped I/O. (c) Hybrid.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 9

10. Direct Memory Access (DMA)
Figure 3-4. Operation of a DMA transfer.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 10

11. I/O Overview Types of I/O devices and speeds
Device controllers and I/O strategies
Memory-mapped I/O, DMA
I/O Software Organization
Device-dependent and device-independent S/W
Resource Access and Management
Deadlocks and deadlock handling
Device Drivers in Minix3
Mass Storage Devices
Disk characteristics, scheduling
Terminals
Character-oriented, bit-oriented displays
Keyboard input handling, scan codes, keymaps, control sequences
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 11

12. Goals of the I/O Software
Figure 3-5. Layers of the I/O software system.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 12

13. Device-Independent I/O Software
Figure 3-6. Functions of the device-independent I/O software.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 13

14. Uniform Interfacing for Device Drivers
Figure 3-7. (a) Without a standard driver interface.
(b) With a standard driver interface.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 14

15. User-Space I/O Software
Figure 3-8. Layers of the I/O system and the main functions of each layer.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 15

16. I/O Overview Types of I/O devices and speeds
Device controllers and I/O strategies
Memory-mapped I/O, DMA
I/O Software Organization
Device-dependent and device-independent S/W
Resource Access and Management
Deadlocks and deadlock handling
Device Drivers in Minix3
Mass Storage Devices
Disk characteristics, scheduling
Terminals
Character-oriented, bit-oriented displays
Keyboard input handling, scan codes, keymaps, control sequences
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 16

17. Resources The sequence of events required to use a resource:
Request the resource.
Use the resource.
Release the resource.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 17

18. Definition of Deadlock
A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 18

19. Example of Deadlock
No car can advance because it is waiting on the car in front of it to get out of the way.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 19

20. Conditions for Deadlock
Mutual exclusion
Hold and wait
No preemption
Circular wait
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 20

21. Deadlock Modeling
Holt graph (Resource Allocation Graph) uses four elements:
1. Resource type = rectangle with number of identical resource instances of that type
2. Process = circle/oval with process name
3. Request arc = arc with arrow pointing from process to resource type requested (opt. with number requested)
4. Allocation arc = arc with arrow pointing from resource type to process to which an instance is allocated (opt. with number of instances allocated to process)
Reverse arc when a request is granted
Reduce graph by eliminating arcs to processes with allocations only, then granting allocations.... but how?
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 21

22. Deadlock Modeling
Figure 3-9. Resource allocation graphs. (a) Holding a resource.
(b) Requesting a resource. (c) Deadlock.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 22

23. Deadlock Avoidance (1)
Figure An example of how deadlock occurs and how it can be avoided.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 23

24. Deadlock Avoidance (1) A B C A B C R S T Request R Request S
Do_stuff(R,S)
Release R
Release S B
Request S
Request T
Do_stuff(S,T)
Release S
Release T C
Request T
Request R
Do_stuff(T,R)
Release T
Release R
A requests R
A gets R
B requests S
B gets S
C requests T
C gets T
A requests S
A is blocked
B requests T
B is blocked
C requests R
C is blocked
Deadlock! A B C R S T
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 24

25. Deadlock Handling Strategies
Ignore the problem altogether (ostrich)
Detection and recovery (optimistic)
Avoidance by careful resource allocation (banker)
Prevention by negating one of the four necessary conditions
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 25

26. Deadlock Prevention (1)
Figure Summary of approaches to deadlock prevention.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 26

27. Deadlock Prevention (2)
Figure (a) Numerically ordered resources. (b) A resource graph.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 27

28. Deadlock Prevention (3)
Two-Phase Locking
Growing phase – acquire locks
Use resources
Shrinking phase – release locks
Prevents roll-backs in transaction systems
Does NOT directly prevent deadlock
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 28

29. The Banker’s Algorithm for a Single Resource
Figure Three resource allocation states: (a) Safe. (b) Safe. (c) Unsafe.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 30

30. Banker's Algorithm Structures
At start, given total number of each resource type that exists in the system (E) and the max possible request for each resource type by each process (Max).
Keep track of allocations of each resource type given to each processes (Has), and get total number of each resource type allocated (P).
Compute residual max need for each process for each resource type (Still Need = Max – Has), and the number of each resource type still available (A = E – P).
For Banker's Algorithm, when process requests one or more resources, pretend to give them to the requesting process and see if the resulting state is safe.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 31

31. The Banker’s Algorithm for Multiple Resources
Figure The banker’s algorithm with multiple resources.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 32

32. The Banker’s Algorithm for Multiple ResourcesD E 2 3 6 3 4 2
Tape
drive
Plotter
Printer CD
ROM
Resource Allocation Graph
with B requesting two CD ROMs
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 33

33. Safe State Checking Algorithm
Look for a row, R, whose unmet resource needs are all smaller than or equal to A. If no such row exists, the system will eventually deadlock since no process can run to completion.
Assume the process of the row chosen requests all the resources it needs (which is guaranteed to be possible) and finishes. Mark that process as terminated and add all its resources to the A vector.
Repeat steps 1 and 2 until either all processes are marked terminated, in which case the initial state was safe, or until a deadlock occurs, in which case it was not.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 34

34. Deadlock Avoidance (1) Max Has Need Exist A B C Available R S T
A requests R
Is it OK to grant?
Sure - A gets R
B requests S
Pretend B gets S
Can all processes
get what they need?
Yes – safe!
So B gets S
C requests T
Pretend C gets T
No process can
fill remaining need
Unsafe!
C must wait
Max
R S T
A 1 1 0
B 0 1 1
C 1 0 1
Has
R S T A B C
Need
R S T A B C 1 1 1 1 1 1 1 1 1
Exist
R S T
1 1 1 A B C
Available
R S T
1 1
0 1 1
0 0 1
0 0 0 R S T 35

35. Deadlock Avoidance (1) Max Has Need Exist A B C Available R S T
A requests S
A is blocked
B requests T
Is it OK to grant?
Pretend B gets T
Can all processes
fill their needs?
Yes – it is safe!
B gets T
B finishes
B releases S
Can A get S now?
A gets S
B releases T
C gets T (it is safe)
C requests R
C is blocked
Max
R S T
A 1 1 0
B 0 1 1
C 1 0 1
Has
R S T A B C
Need
R S T A B C 1 1 1 1 1 1 1 1 1 1 1
Exist
R S T
1 1 1 A B C
Available
R S T
0 0 1
0 0 0
0 1 0 R S T
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 36

36. Deadlock Detection/Recovery
Only consider actual pending resource requests (not the maximum possible as in Banker's Algo). Processes with no pending requests are not blocked, hence can be “satisfied” immediately.
Run same loop as Safe State Checking algorithm, looking for processes whose pending requests can be satisfied with the resources currently available, then marking them and adding the resources they hold to those available.
If any processes are not marked when no more can be satisfied, then they are part of a deadlock. Only processes involved in a deadlock need be preempted.
Pick a process to preempt, release its resources, and run algorithm again to see if deadlock(s) are now gone.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 37

37. I/O Overview Types of I/O devices and speeds
Device controllers and I/O strategies
Memory-mapped I/O, DMA
I/O Software Organization
Device-dependent and device-independent S/W
Resource Access and Management
Deadlocks and deadlock handling
Device Drivers in Minix3
Mass Storage Devices
Disk characteristics, scheduling
Terminals
Character-oriented, bit-oriented displays
Keyboard input handling, scan codes, keymaps, control sequences
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 38

38. Device Drivers in MINIX 3 (1)
Figure Two ways of structuring user-system communication.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 39

39. Device Drivers in MINIX 3 (2)
Figure Fields of the messages sent by the file system to the block device drivers and fields of the replies sent back.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 40

40. Device-Independent I/O Software in MINIX 3
Figure Outline of the main procedure of an I/O device driver.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 41

41. Block Device Drivers in MINIX 3
Figure A shared I/O task main procedure using indirect calls.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 42

42. Device Driver Operations
OPEN
CLOSE
READ
WRITE
IOCTL
SCATTERED_IO
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 43

43. RAM Disk Hardware and Software
Figure A RAM disk.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 44

44. I/O Overview Types of I/O devices and speeds
Device controllers and I/O strategies
Memory-mapped I/O, DMA
I/O Software Organization
Device-dependent and device-independent S/W
Resource Access and Management
Deadlocks and deadlock handling
Device Drivers in Minix3
Mass Storage Devices
Disk characteristics, scheduling
Terminals
Character-oriented, bit-oriented displays
Keyboard input handling, scan codes, keymaps, control sequences
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 45

45. Mass Storage Devices Tape Drum Disk Solid state (thumb drive)
Sequential access to records
Drum
Multiple tracks on rotating drum – rotational latency
One (or more) head per track – no seek time
High rotational speed (e.g., 12,500 rpm) – backing store
Disk
One or more platters, two sides per platter
Data arranged in tracks and sectors
One head per side
Head must move to track (seek time)
Must wait for sector to rotate under head (rotational latency)
Solid state (thumb drive)
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 46

46. Block Structured Devices
Data stored in blocks
Amortize large setup costs over block of data
Must pay cost of block access for even one byte
Block buffers
Store copy of block in RAM for future accesses
Amortize block transfer cost over multiple accesses
Issue of consistency between RAM and persistent store
Consistency
Writes stored to buffered copy in RAM
Synchronize to disk periodically or on explicit command
Block structure
Header with location info
Trailer with error detection/correction code
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 47

47. Drum Note multiple heads per track (faster) – usually just one
Invented in 30’s, used in 50’s-70’s – KB typical
Fast backing store – used for paging systems (Chapter 4)
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 48

48. Hard Disk One head per side – multiple platters Invented in 50’s
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 49

49. Hard Disk … Read-write head track … arm sector
Multiple (perhaps variable) sectors per track
Arm must move to correct track (or cylinder when multiple platters), then wait for sector to spin under head
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 50

50. Disk Software Read/Write timing factors: Seek time Depends on drive
Rotational delay
Data transfer time
Slow (ms per track)
Medium (fcn of rpm)
Fast (fcn of rpm and
sectors/track)
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 51

51. Rotational Effects Rotational delay Suppose disk rotates at 6000 rpm
Q: What is maximum rotational latency?
(6000rmp)/(60 sec/min) = 100 rev/sec
10 msec per rotation (max latency)
Q: What is average rotational latency?
Expect to wait ½ of a rotation =>
5 msec average
Data transfer time
adfa
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 52

52. Rotational Effects Data transfer time Suppose disk rotates at 6000 rpm
Suppose 100 sectors/track
Q: What is data xfer time per sector?
(6000rmp)/(60 sec/min) = 100 rev/sec
10 msec per rotation/100 sectors/rotation
= 0.1 msec per sector
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 53

53. Rotational Effects Data transfer rate Suppose disk rotates at 6000 rpm
Suppose 100 sectors/track, 512 B/sector
Q: What is data xfer rate?
From before, 0.1 msec per sector, so
(512 B/sector)/(10-4 sec/sector) =
5,120,000 Bps = Mbps
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 54

54. Rotational Effects Effective data rate to transfer one sector…
Same disk as before – but now account for rotational latency
Q: What is effective data xfer rate for one sector, if the head is on the right track?
From before, 0.1 msec per sector, and 5 msec rotational latency, so 5.1 msec total
(512 B/sector)/(5.1x10-3 sec/sector) =
103,900 Bps = 0.8 Mbps (ouch!)
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 55

55. Seek Time Effects
Suppose that the stepper motor takes 1 msec per track to move the head
Suppose there are 100 tracks
Q: What is average seek time?
(Assume uniform random start and finish)
Average distance is about (100/3)
At 1 ms/track this give about 33.3 msec.
Q: Now what is the effective data rate?
R = (512 B)/( ms) = 13.3 kBps
= 107 kbps. Yuck!
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 56

56. Disk Arm Scheduling Algorithms (1)
Sequence of seeks
Figure Shortest Seek First (SSF) disk scheduling algorithm.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 57

57. Disk Arm Scheduling Algorithms (2)
Sequence of seeks
Figure The elevator algorithm for scheduling disk requests.
Question: What is the optimum seek sequence?
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 58

58. Common Hard Drive Errors
Programming error - request for nonexistent sector
Transient checksum error - caused by dust on the head
Permanent checksum error - disk block physically damaged
Seek error - the arm sent to cylinder 6 but it went to 7
Controller error - controller refuses to accept commands
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 59

59. Hard Disk Driver in MINIX 3 (1)
Figure (a) The control registers of an IDE hard disk controller. The numbers in parentheses are the bits of the logical block address selected by each register in LBA mode.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 60

60. Write Precompensation
A circular disk drive platter is divided into sectors (pie slices).
If the same number of sectors are placed on an outer track as on an inner track, the sectors are physically smaller on the inner track. (see next slide)
However, all the sectors hold the same amount of data.
Write precompensation causes the drive to increase the current used when writing to the inner tracks to compensate for the greater density. But where?
The write precompensation field in the control registers for a drive indicates the track number where write precompensation begins.
Many modern disks have a variable number of sectors per track, and do not need write precompensation.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 61

61. Hard Disk … Read-write head track … arm sector
Multiple (perhaps variable) sectors per track
Arm must move to correct track (or cylinder when multiple platters), then wait for sector to spin under head
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 62

62. Hard Disk Driver in MINIX 3 (2)
Figure (b) The fields of the Select Drive/Head register.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 63

63. Floppy Disk Drive
Floppy is similar to hard drive in access, but has added hair.
Characteristics that complicate the driver:
Removable media
Multiple disk formats.
Motor control.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 64

64. I/O Overview Types of I/O devices and speeds
Device controllers and I/O strategies
Memory-mapped I/O, DMA
I/O Software Organization
Device-dependent and device-independent S/W
Resource Access and Management
Deadlocks and deadlock handling
Device Drivers in Minix3
Mass Storage Devices
Disk characteristics, scheduling
Terminals
Character-oriented, bit-oriented displays
Keyboard input handling, scan codes, keymaps, control sequences
Mouse input
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 65

65. Figure 3-24. Terminal types.
Terminal Taxonomy
Figure Terminal types.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 66

66. Memory-Mapped Terminals
Figure Memory-mapped terminals write directly into video RAM.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 67

67. RS-232 Terminals
Figure An RS-232 terminal communicates with a computer over a communication line, one bit at a time. The computer and the terminal are completely independent.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 68

68. Terminal Input Modes Canonical (cooked) mode Raw mode cbreak Mode
Line at a time input
Must still echo characters when typed
But allow user to correct input before processing
Raw mode
Characters can be passed to the process as they are typed
Used for games, visual editors, etc.
Program interprets meaning of each character
cbreak Mode
Similar to raw
But INTR, QUIT, START, STOP retain effects
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 69

69. Special Input Characters
Figure Characters that are handled specially in canonical mode.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 70

70. Buffering Terminal Input
Allows user to type ahead
Buffers
are big
enough
for all
typing
(100’s
of bytes)
Buffers in
pool are
typically
small
(8-16 bytes)
Figure (a) Central buffer pool. (b) Dedicated buffer for each terminal.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 71

71. When to Return in Raw Modes
Figure MIN and TIME determine when a call to read returns in noncanonical mode. N is the number of bytes requested.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 72

72. Keyboard Driver (1)
Figure Scan codes in the input buffer, with corresponding key actions below, for a line of text entered at the keyboard. L and R represent the left and right Shift keys. + and - indicate a key press and a key release. The code for a release is 128 more than the code for a press of the same key.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 73

73. Recall Keyboard Driver (2)
Figure Escape codes generated by the numeric keypad. When scan codes for ordinary keys are translated into ASCII codes the special keys are assigned ‘‘pseudo ASCII’’ codes with values greater than 0xFF.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 74

74. Figure 3-37. A few entries from a keymap source file.
Loadable Keymaps
Figure A few entries from a keymap source file.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 75

75. Terminal Driver Support Code
Figure The fields in a character code as it is placed into the input queue.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 76

76. Output Software (2)
Figure The ANSI escape sequences accepted by the terminal driver on output. ESC denotes the ASCII escape character (0x1B), and n, m, and s are optional numeric parameters.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 77

77. Input Software – termios struct
Figure The termios structure. In MINIX 3 tc_flag _t
is a short, speed_t is an int, and cc_t is a char.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 78

78. Device-Independent Terminal Driver (1)
Figure Default termios flag values.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 79

79. Terminal Driver in MINIX (1)
Terminal driver message types:
Read from the terminal (from FS on behalf of a user process).
Write to the terminal (from FS on behalf of a user process).
Set terminal parameters for IOCTL (from FS on behalf of a user process).
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 80

80. Terminal Driver in MINIX (2)
Terminal driver message types (continued):
I/O occurred during last clock tick (from the clock interrupt).
Cancel previous request (from the file system when a signal occurs).
Open a device.
Close a device.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 81

81. Terminal Input (1)
Figure Read request from the keyboard when no characters are pending. FS is the file system. TTY is the terminal driver. The TTY receives a message for every keypress and queues scan codes as they are entered. Later these are interpreted and assembled into a buffer of ASCII codes which is copied to the user process.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 82

82. Terminal Input (2)
Figure Input handling in the terminal driver. The left branch of the tree is taken to process a request to read characters. The right branch is taken when a keyboard message is sent to the driver before a user has requested input.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 83

83. Figure 3-43. The function keys detected by func_key().
Keyboard Driver
Figure The function keys detected by func_key().
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 84

84. Terminal Output (1)
Figure Major procedures used in terminal output. The dashed line indicates characters copied directly to ramqueue by cons_write.
Note: “pause_escape” should be “parse_escape” in figure
parse escape
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 85

85. Memory-Mapped Terminals
Figure Memory-mapped terminals write directly into video RAM.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 86

86. VRAM
Figure (a) A video RAM image for the IBM monochrome display. (b) The corresponding screen.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 87

87. Terminal Output (2)
Figure Fields of the console structure that relate to the current screen position.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 88

88. Terminal Output (3)
c_start points to start of RAM allocated for console display (origin).
c_limit indicates the end of the RAM allocated for console display.
These are constants set by the system.
c_org is where the controller starts reading in RAM for first line, and all locations for character displays are relative to this location.
c_row and c_column indicate current position relative to upper left corner of display.
c_curr can be derived from c_row, c_column, and c_start, but is kept redundantly to make operation faster.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 89

89. VRAM
c_limit
c_cur
c_org
c_start
Figure (a) A video RAM image for the IBM monochrome display. (b) The corresponding screen.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 90

90. Hardware Scrolling in VRAM
screen
Bar.o
> vi Foo.c
> make Foo
cc -Wall –o Foo Foo.c
> ls
Bar
Bar.c
Foo.c
Foo.o
Foo
> vi Bar.c
> make Bar
cc -Wall –o Bar Bar.c
>
Bar
Bar.c
Bar.o
>vi Foo.c
> make Foo
cc -Wall –o Foo Foo.c
> ls
Foo.c
Foo.o
Foo
> vi Bar.c
>
> ls
Bar
Bar.c
Bar.o
>vi Foo.c
> make Foo
cc -Wall –o Foo Foo.c
Foo.c
Foo.o
Foo
>
c_limit
c_cur
c_org
c_start _
So what happens when c_limit reached?
Part of VRAM displayed
Scrolling can be done in hardware by changing the location where the video controller start reading characters (c_org)
As cursor location changes, so does c_cur
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 91

91. Figure 3-45. Some of the 6845’s registers.
Display Driver (2)
Figure Some of the 6845’s registers.
Values are copied from console structure into video controller registers to change what is displayed
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 92

92. Device-Independent Terminal Driver (2)
Figure POSIX calls and IOCTL operations.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 93

93. Output Software (1)
Figure The ANSI escape sequences accepted by the terminal driver on output. ESC denotes the ASCII escape character (0x1B), and n, m, and s are optional numeric parameters.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 94

94. Output Software (2)
Figure The ANSI escape sequences accepted by the terminal driver on output. ESC denotes the ASCII escape character (0x1B), and n, m, and s are optional numeric parameters.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 95

95. Figure 3-44. Finite state machine for processing escape sequences.
Display Driver FSM
Figure Finite state machine for processing escape sequences.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 96

96. PS2 3-Byte Mouse Serial Packet Format
Mouse Input
Bit 7
Bit 6
Bit 5
Bit 4
Bit 3
Bit 2
Bit 1
Bit 0
Byte 1 YV XV YS XS 1 MB RB LB
Byte 2
Byte 3
X movement
Y movement
V – overflow
S – sign
B – button (1 = pressed, 0 = not pressed)
Movement measured in “mickeys” or pulses detected
Packet sent on movement or button state change
Converted to screen motion of cursor in software with scale factor (speed)
Software can also change scale factor according to motion
PS2 3-Byte Mouse Serial Packet Format
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved 97