Lecture 14 - More on IO Software

Tips for Lab 3

What is ipc.h? It is a union of a bunch of structures? How do you use them? Look at com.h.

Also look at the back half of chapter 3 for answers for lab 3.

More on IO

The goal for this lecture is to talk about the ISR and generic interrupts. We want to have:

• abstraction: to hide complexity
• organization/standardization: we should only care about files, not the hard drives
• error handling: fix and give a useful error message
• synchronization: make operations make sense (asynchronized, but in step)

Components of IO software include:

• Interrupt handlers (essentially the ISR)
• Device dependent software (disk drivers, for example) (you want this to be as small and repeatable as possible to reduce repeated work)
• Device Independent (nothing device specific)
• User-level software

$\text{Minix}$ has its own IPC (inter-process control):

• send(dst, msg)
• recv(src, msg)
• send_rec(oth, msg)
  These are all synchronous (via rendezvous). One thing is that anything lower than user-processes can only send or recv so that if user processes block for these messages, then they won't block forever on the lower processes (they don't block).

$\text{Minix}$ also only has 1 asynchronous interrupt IPC:

• notify(dst)

How do we make these Interrupt Handlers?

It obviously handles interrupts. Remember, this only runs when there's an interrupt. That means that:

• they are immediate (you don't know when they're going to run)
• it'll do something (usually tell the device that you got the interrupt) & tell someone to run
  What it runs may be simple. For example, a disk interrupt is so infrequent that you may not have to worry about interrupts when running the ISR.

A more complex example would be a terminal. Every single character you type has to be handled. Every time, you release, a key. You need to be handle these interrupts, and stacks of them.

Another complex example is the clock. If it has to count the number of ticks++; for every interrupt, you'll have to make it much more versatile (what happens if there's many other interrupts).

Device Tasks

We'll have device tasks, which are just state machines:

initialize();
for(;;){
	recv(oth, msg);
	switch(m, m_type){
		// do something
	}
	send(m, m_sound, reply);
}
cleanup();

Disk Scheduling

The $\text{Minix}$ disk scheduling algorithm is pretty simple:

• FCFS
• Shortest seek first ()

This is a problem with elevators, so we have an algorithm from it called the elevator algorithm. Using only one bit of state direction, it's a simple and effective way of solving this problem.