EEE 435 Principles of Operating Systems

1
EEE 435Principles of Operating Systems

• Principles and Structure of I/O Software
• (Modern Operating Systems 5.2 5.3)

2
Quick Review

• What is burst mode?
• On which stack is the state of the system saved
  when an interrupt occurs?

3
Outline

• Principles and goals of I/O software
• I/O Methods
• I/O Software Structure (Part I)

4
Principles/Goals of I/O Software

• Device Independence
• Should be possible to write programs that can
  access any I/O device without having to specify
  the device in advance
• For example your program should not be
  substantially different (if at all!) if you open
  a file on floppy, hard drive, or CD-ROM

5
Principles/Goals of I/O Software

• Uniform Naming
• The name of a file or device should be a string
  or integer and not depend on the device in any
  way
• Does the Windows system achieve this goal?
• Error Handling
• Errors should be handled as close to the hardware
  as possible
• ie controller-gtdevice driver-gtand upwards
• Many I/O errors are transient trying again will
  generally remove the error

6
Principles/Goals of I/O Software

• Synchronous vs Asynchronous transfers
• At the physical level, most I/O is asynchronous
• The device signals an interrupt when ready
• For the user, the program is usually much easier
  to create if the I/O is synchronous (ie
  blocking)
• It is up to the operating system to make
  asynchronous transfers appear blocking to the user

7
Principles/Goals of I/O Software

• Buffering
• Data that comes off a device must often be
  collected before being given to its final
  destination
• For example, a packet from a network must be
  examined to determine which process requested the
  packet
• Data going to a device might also be buffered.
  For example mp3 player must have data ready to
  read at all times
• This decouples the fill rate from the empty rate

8
Principles/Goals of I/O Software

• Sharable vs. Dedicated Devices
• Some devices, such as disks, can be shared by
  multiple processes simultaneously. Multiple
  files can be opened at the same time without
  problem
• Other devices, such as tape drives or CD burners
  may only have a single user until their job is
  complete
• Dedicated devices also introduce the problem of
  deadlocks

9
How is I/O Performed?

• Three methods
• Programmed I/O
• Interrupt-Driven I/O
• DMA
• This is from the point of view of the software,
  although it may involve some hardware issues...

10
How is I/O Performed?

• Programmed I/O
• This is I/O through busy waiting
• The OS has a process sitting in a loop, checking
  to see if the device is ready to communicate and
  sending/receiving information as required

11
How is I/O Performed?

• Programmed I/O
• This method is simple to implement, but ties up
  the CPU full time (if not using a process to
  print) or a lot of CPU cycles
• If wait time is short (ie printing goes to a
  buffer inside the printer) this could be
  acceptable

12
How is I/O Performed?

• Interrupt-Driven I/O
• This method allows the CPU to do other work while
  I/O is pending
• As before, the information to be printed is
  copied to kernel space
• The printer is then fed the first character and
  the scheduler called to run another process (part
  of system call)
• When the printer is ready for a character, an
  interrupt is generated and the printer interrupt
  service procedure executed

13
How is I/O Performed?

• Interrupt-Driven I/O
• If the ISP notes that there are no characters
  left to print the user process is unblocked
• Could be through a message, semaphore, etc

14
How is I/O Performed?

• I/O Using DMA
• Big gain this allows only one interrupt per
  transfer when the I/O is complete!
• It is essentially using programmed I/O again, but
  the DMA controller is doing the work instead of
  the CPU
• If the CPU is usually idle, then this method is
  less efficient than interrupts. Why?

15
I/O Software has Layers (like Ogres)

• How is I/O software organized?
• Four levels, each more abstract from the hardware
  than the previous
• Each layer has a well defined interface to its
  adjacent layer

16
I/O Software has Layers (like Ogres)

• Interrupt Handlers
• Interrupts must be used for at least part of
  dealing with I/O and should be hidden as far away
  from the user as possible, in the bowels of the
  operating system
• Best way to deal with them is to have the driver
  block itself with a semaphore, a wait condition
  on a variable, a receive on a message, or some
  similar method
• When the interrupt arrives, the driver is
  unblocked/messaged/etc...

17
I/O Software has Layers (like Ogres)

• Interrupt Handlers
• Of course, it isnt that simple. Much more has
  to be accomplished when responding to an
  interrupt
• Save any registers that were not saved by
  hardware
• Set up TLB, MMU, page table, and stack for the
  ISR
• Acknowledge the interrupt controller (or device
  if none)
• Copy the registers from where they were saved to
  the process table
• Run the ISR (get device info, unblock the driver,
  etc)
• Choose next process to run and set up the MMU,
  TLB, registers, PSW, PC, etc for that process
• Start running the newly selected process

18
I/O Software has Layers (like Ogres)

• Device Drivers
• Each I/O device attached to the computer requires
  specific code to control it known as the device
  driver
• This is because, at the hardware level, devices
  look radically different from one another
• Sometimes one driver will handle a class of
  closely related devices. eg a number of mice
• The device driver is generally written by the
  device manufacturer and for a number of popular
  operating systems

19
I/O Software has Layers (like Ogres)

• Device Drivers
• Typically, drivers live in the kernel so they can
  access the control registers of the device
• This isnt a requirement. You could have device
  drivers in user space and have system calls for
  register communication. However, it is the
  state of the practice
• Given that this is usually the method of
  implementing drivers, the standard architecture
  is to have the drivers below the bulk of the OS

20
I/O Software has Layers (like Ogres)

• Not shown, but OSs usually require all block
  devices to support a standard set of interfaces
  and all character devices to support a different
  set

21
I/O Software has Layers (like Ogres)

• What do device drivers do?
• Accept the abstract read/write commands from the
  layer above
• Assorted functions
• Initialize the device
• Manage its power

22
I/O Software has Layers (like Ogres)

• What does a driver do on a read/write?
• Check input parameters return errors
• Convert abstract commands (read from sector) to
  physical terms (head, track, sector, and
  cylinder)
• Queue requests if device is busy
• Bring device to running status,if required
• May need to get motor up to speed, etc...
• Control the device by issuing a number of
  commands to it through the control registers

23
I/O Software has Layers (like Ogres)

• What does a driver do on a read/write?
• Once request is issued one of two situations will
  occur
• The driver must wait for the request to complete,
  so it blocks. It will be awakened later, as
  described in the section on interrupts
• The result is instantaneous(eg writing to screen
  memory) so work is continued until all I/O is
  complete

24
I/O Software has Layers (like Ogres)

• Device Driver real-world complications
• Interrupt received for driver while performing
  I/O
• May happen where a network packet being assembled
  and a new packet is received
• Driver code must be reentrant in this case
• Devices may be added/removed while computer is
  running

25
Quiz Time!

• Questions?