Hardware OS & OS- Application interface Summer 2016 Cornell - - PowerPoint PPT Presentation

hardware os os application interface summer 2016 cornell
SMART_READER_LITE
LIVE PREVIEW

Hardware OS & OS- Application interface Summer 2016 Cornell - - PowerPoint PPT Presentation

CS 4410 Operating Systems Hardware OS & OS- Application interface Summer 2016 Cornell University 1 Today HW-OS interface OS-App interface Protection 2 How can an editor use a keyboard? keyboard keyboard controller CPU


slide-1
SLIDE 1

1

CS 4410 Operating Systems

Hardware – OS & OS- Application interface

Summer 2016 Cornell University

slide-2
SLIDE 2

2

Today

  • HW-OS interface
  • OS-App interface
  • Protection
slide-3
SLIDE 3

3

How can an editor use a keyboard?

memory CPU keyboard editor OS keyboard driver keyboard controller

slide-4
SLIDE 4

4

A modern computer system

Graphics adapter CPU Disk controller USB controller disks mouse keyboard printer monitor memory app OS device driver app app device driver

slide-5
SLIDE 5

5

HW-OS interface

memory CPU device application OS device driver device controller

slide-6
SLIDE 6

6

HW-OS interface

  • Device Controller:
  • A set of chips on a plug-in board.
  • It has local buffer storage and/or a set of special purpose

registers.

  • Responsible for moving data between device and

registers/buffer.

  • Responsible for making data available to the device

driver.

slide-7
SLIDE 7

7

HW-OS interface

  • Device Driver:
  • Belongs to the OS.
  • Communicates with the device controller.
  • Presents a uniform interface to the rest of the OS.
slide-8
SLIDE 8

8

Driver to Controller

  • Memory-mapped I/O
  • Device communication goes over the memory bus
  • Reads/Writes to special addresses are converted into I/O operations by dedicated

device hardware

  • Each device appears as if it is part of the memory address space
  • Programmed I/O
  • CPU has dedicated, special instructions
  • CPU has additional input/output wires (I/O bus)
  • Instruction specifies device and operation
  • Memory-mapped I/O is the predominant device interfacing technique in use

device controller device driver CPU

slide-9
SLIDE 9

9

Controller to Driver

  • Polling
  • CPU constantly checks controller for new data
  • Inefficient
  • Interrupts
  • Controller alert CPU for an event
  • Interrupt driven I/O
  • Interrupt driven I/O enables the CPU and devices to

perform tasks concurrently, increasing throughput.

device controller device driver CPU device OS

slide-10
SLIDE 10

Example: Reading data from disk

  • Disk’s device driver (in OS) executes a read command (memory-mapped I/O).
  • CPU writes the read’s descriptor to the disk’s controller register.
  • CPU executes another computation.
  • The disk asynchronously performs the read operation.
  • When the read operation completes, by putting the requested data in disk controller’s buffer,

the device controller interrupts the CPU (Interrupt driven I/O).

  • The CPU stops the current computation.
  • The CPU transfers the execution to the disk’s device driver (which was waiting for this read to

complete).

  • The disk’s device driver executes by moving the requested data from disk controller’s buffer to

memory.

  • On completion, the CPU resumes the interrupted computation.
  • BUT, this would incur high-overhead for moving bulk-data. One interrupt per byte!
slide-11
SLIDE 11

11

Direct Memory Access (DMA)

  • Transfer data directly between device controller and memory.
  • No CPU intervention required for moving bytes.
  • Device raises interrupts solely when the block transfer is

complete.

  • Critical for high-performance devices.
slide-12
SLIDE 12

12

OS-App interface

memory CPU device OS device driver device controller application

slide-13
SLIDE 13

OS-App interface

  • Driver to Application:
  • Pass data from OS memory space to application memory

space.

  • Application to Driver:
  • System Calls
  • Like calling a routine of the OS.
  • Examples: print a character, send a packet, read a block

from disk.

slide-14
SLIDE 14

Protection

  • OS is necessarily trusted to do anything with the

hardware.

  • Applications are untrusted; they should not have

complete control of the hardware.

  • For example, applications should not be able to:
  • access memory own by other application, or
  • disable interrupts.
  • CPU needs to distinguish whether an instruction is

executed on behalf of the OS or on behalf of an application.

slide-15
SLIDE 15

Dual-mode operation

  • Use a privilege mode bit in CPU.
  • On user mode, CPU checks whether each instruction is

allowed.

  • On kernel mode, CPU applies no check.
slide-16
SLIDE 16

Example: changing privilege mode

User Mode Kernel Mode

System call, or Interrupt, or Processor exception Return

slide-17
SLIDE 17

Synchronous VS asynchronous events…

… with respect to the execution of an application.

  • Synchronous
  • Events triggered by the execution of the application.
  • Example: systems call, process exception (i.e. division by 0).
  • Asynchronous
  • External events; not triggered by the application.
  • Example: intervals.
  • In both cases, CPU stops executing the application, saves

the execution state, and executes the corresponding handler in the OS.

slide-18
SLIDE 18

18

Today

  • HW-OS interface
  • OS-App interface
  • Protection
slide-19
SLIDE 19

19

Coming up…

  • Next lecture: Processes and Threads
  • HW1:
  • HW-OS-App interface
  • Due on Monday, 10pm.
  • No in-class exam next week.
  • CMS invitation?
slide-20
SLIDE 20

Game! Communication between PDFviewer and hard disk

1) The device controller retrieves desired data and store them in the local buffer. 2) The driver handles the system call. 3) PDFviewer issues a system call to read data. 4) The driver writes a “read descriptor” to the device controller using memory mapped I/O. 5) The device controller uses DMA to transfer data to driver’s memory. 6) The device controller causes an interrupt. 7) The system call returns successfully. 8) The device driver copies data to the memory space of PDFviewer.

slide-21
SLIDE 21

Solution

3) PDFviewer issues a system call to read data. 2) The driver handles the system call. 4) The driver writes a “read descriptor” to the device controller using memory mapped I/O. 1) The device controller retrieves desired data and store them in the local buffer. 5) The device controller uses DMA to transfer data to driver’s memory. 6) The device controller causes an interrupt. 8) The device driver copies data to the memory space of PDFviewer. 7) The system call returns successfully.