Overview

• deadlocks
• Minix system task
• Minix clock task
• Minix virtual memory
• Overview of Minix I/O
• Minix Block Devices

user software I/O

• user software knows what contents to put in what files, what files to read, what data to send, what to display on the screen, etc
• some I/O functions, such as spooling print files, running routing protocols, or network services, is usually implemented by user-level processes known as daemons or servers

deadlocks

• formal definition:

  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

• the event is usually the release of a resource, typically a lock
• this definition generalizes the common definition, which is a cycle of resource requests among processes

conditions for deadlock

• mutual exclusion: resources cannot be assigned to more than a finite number of processes at any given moment
• hold and wait: processes holding resources will wait if their requests cannot be satisfied immediately
• no preemption: resources cannot be taken away from processes that own them
• circular wait: there must be a cycle of resource requests among the processes

solutions for deadlock

1. don't try too hard to avoid it. E.g. if the situation is really unlikely, and other things cause greater unreliability, don't waste effort trying to avoid deadlock
2. prevent processes holding resources from waiting, e.g. by requesting all resources at once, or by failing (gracefully) any process whose request cannot be granted
3. allocate all resources in a fixed order, e.g. all printers before all disk drives, and devices of one class in ascending order. This works if (a) all processes obey this, and (b) such an order can be defined
4. if resource requests are known in advance, can compute in advance (using the Banker's algorithm whether granting a request would make the system unsafe, and therefore refusing or delaying the request

PC Clock Hardware

• quartz crystal oscillator drives counter
• when counter reaches maximum, reloaded with contents of a register, and also interrupts
• for example, 32.000KHz quartz, 8-bit counter loaded with 224 = 256-32, when overflows, 1ms has passed, reload with 224
• the initial contents of the register controls the frequency of interrupts, e.g. for one interrupt every 2ms, load with 192
• real-time clock is a separate device, uses a very low-power counter similar to those found on digital watches, battery keeps it running when main power is off

Minix Clock Driver

• very understandable driver
• runs in kernel address space, to avoid overhead of regular communications mechanisms
• interrupt handler does not conform to the Minix model:
  • interrupt handler is specific rather than generic
  • interrupt handler often does not send a message to the driver
  • interrupt handler does substantial work
• all of these are in the interest of speed on slow systems
• functions:
  • maintain the time of day
  • preempt processes
  • account for CPU usage and support profiling
  • provide alarm signals for user processes and watchdog timers for other parts of the system

Time of day support

• 32-bit counter in seconds rolls over in about 136 years
• 32-bit counter in ticks (1/60 of a second) rolls over in about 2 years
• time is usually counted in seconds from Jan 1st, 1970 (Unix, Minix, etc) or Jan 1st, 1980 (Windows) -- this is the epoch
• options:
  • keep 64-bit counter in ticks
  • keep 32-bit counter in seconds and another variable to record the fractional ticks
  • use boot time as the epoch and keep a 32-bit count of ticks. Separately record the boot time (in seconds) as a 32-bit variable. Minix uses this
• getting the time of day: add realtime / HZ to the boot time
• setting the time of day: save the difference between the parameter and realtime / HZ as the new "boot" time

Supporting Alarms and Watchdogs

• alarm (22) in a user program tells the system to send a signal to the process unless the alarm has been cleared within 22 seconds
• in Minix, drivers and servers can set watchdog timers which result in sending a message when the time expires
• in Minix, servers can request synchronous alarms before calling receive, so the call to receive is guaranteed to eventually terminate
• most of the support for signals is in the servers, but the clock task must send a message to the process manager (if PM is receiving, otherwise just set some bits) to tell it to signal the process
• watchdogs simply require sending a message (notify)
• the clock driver is slightly more general, and calls an arbitrary function, which happens to always be cause_alarm in the system task (p. 763)
• this function can never block, otherwise the clock task would be blocked and pre-emption would not be performed (though interrupts would still happen and realtime would still be correct)

Minix System Task

• coordination between the drivers, servers, user processes, and the kernel is essential
• in Minix, kernel functions needed by the servers or drivers are placed in the system task
• like all tasks, the system task receives messages, executes appropriate code, and returns results, without blocking
• a special call, cause_sig (p. 199), sends a signal to a user process:
  • a bit is set in the process's pending signal bitset
  • if the process was executable, it is dequeued
  • a notification is sent to the process manager
• a number of calls perform the kernel portion of process management system calls: fork, exec, exit, times, kill.
• other calls perform tasks on behalf of the process manager or file server, for example mapping memory to a process, copying data between adress spaces, converting virtual to physical addresses, tracing a process execution, and rebooting or shutting down the system

Supporting Fork and Exec

• fork (p. 881) requires copying the proc table entry (the PM has already selected the child process ID), splitting the remaining quantum among parent and child, changing the return value for the child (which is returned in the reply message), and clearing the usage times
• some of this is done in kernel/system/do_fork.c (not in the book)
• and in servers/vfs/misc.c (not in the book)
• pending and enabled signals should only be kept by the parent
• exec resets the stack pointer and places a new PC in the process table, then readies the process for execution. Someone else must map the new code segments to the memory before calling this code
• exit does bookkeeping and removes the process from any queues for any messages it was trying to send, then cancels signals and sets the slot to free -- someone else is responsible for closing file descriptors, deallocating memory, etc
• microkernel design clearly separates responsibilities, but any significant task is likely to involve many parts of the code -- there are several separate process tables that all need to be kept in sync

Minix kernel tasks

• the clock task and the system task are separately schedulable, but run in kernel space
• these are essentially threads of the kernel "process"
• so the minix kernel has three threads: the message passing code, which includes the scheduler/message passing, the clock thread, and the system thread
• each of these threads executes briefly, then suspends again

Virtual Memory in Minix

• umap_local, umap_remote, umap_bios, starting on p. 760
• a virtual address vir_addr corresponds to a physical address pa based on two per-segment fields, mem_vir and mem_phys (see lines 10015 and 10018.)
• possible segments include text, data, and stack
• vir_addr - mem_vir is the offset o into the segment
• p = o + mem_phys is the physical address
• computation on lines 10015-10019
• all computations aligned on "page" (click) boundaries

Minix I/O

• structure reflects conceptual structure of:
  1. device-specific I/O: drivers, implemented as driver processes
  2. device-independent I/O: server layer
  3. user-level I/O: user process layer

Minix device drivers

• device drivers execute as separate processes, and (after initialization) only when they receive a message
• user processes send messages to the file system or PM server, and servers send messages to the device drivers
• device drivers may also receive messages from the interrupt handlers
• interrupt handler messages carry no data, they are just notifications
• messages from the servers may carry information about the (minor) device number, which process is requesting the I/O, how many bytes are requested, where on the device and where in memory the bytes are or should be placed, and especially what operation is requested

Minix device driver threading

• each device driver may be interrupted, but no variables are shared with other device drivers, so there can be no race conditions: each device driver is much like a monitor
• device drivers may receive messages, and therefore suspend
• the block-device drivers will only accept messages from the interrupt handler while they are waiting for a result, so (like a non-waiting monitor) these device drivers are not re-entrant
• the terminal task will accept keyboard input while waiting for a response from a serial line read, but will not accept further requests for keyboard input until the first one has been satisfied

Minix device driver structure

• a device driver must:
  1. initialize its device(s)
  2. loop forever,
     1. receiving a message (usually device drivers block here)
     2. carrying out the message (occasionally device drivers block here)
     3. sending a response (device drivers should never block here)
• all the block device drivers (RAM, floppy, hard disk, CD, SCSI) share similar functions, and are implemented with a single, generic main loop in drivers/libdriver/driver.c, p. 773
• the generic main loop uses an array of function pointers (of type struct driver, p. 770) to execute device-specific operations

Minix block driver

• for example, a dev_open message results in a call to (*dp->dr_open)(dp, &mess)
• drivers/libdriver/driver.c contains generic versions for some of these functions, for example do_rdwt, which calls

  (*dp->dr_prepare)(mp->DEVICE);
  ...
  (*dp->dr_transfer)(mp->PROC_NR, opcode, mp->POSITION, &iovec1, 1);
  ...
  

• at the end of each request, the device gets to

  (*dp->dr_cleanup)();
  

• if a block device chooses to use do_rdwt, it can implement these functions to provide the desired functionality
• for example, for the RAM disk, m_transfer can perform the I/O, and m_prepare just verifies the device number and returns the device base and size
• in contrast, for the hard disk (at_wini), w_transfer sets up the operation, then waits for the transfer to complete
• the wait can be waiting for an interrupt (line 12898) in case of read, or waiting in a busy loop (line 12909) in case of a write
• in-class question: the "interrupt wait" waits for an interrupt, but will receive from ANY (line 13132), which means it may discard a message. Why not listen to a message from the hardware only? Why does the driver never get a message from another source while waiting for its interrupt? (5 minutes)

File and Block I/O structure

• all device-independent file operations are done by the FS server
• this includes interfacing to device drivers, buffering, error reporting, and using a device-independent block size

Block I/O operations

• open a device -- check to make sure it is actually there, initialize it, read the partition table
• close a device
• read a block, specifying the start location on disk, the number of bytes, and the buffer address
• write a block, specifying the start location on disk, the number of bytes, and the buffer address
• IOCTL a device, getting or setting the partition table to/from memory
• do a scattered read or a scattered write, providing an array of blocks to be read or written

Scattered I/O operations

• each scattered operation is a collection of reads or writes of individual (variable sized) blocks
• each Minix 3 scattered operation is all reads or all writes
• each Minix 3 scattered operation is sequential on the device, but the source/results may be scattered among different buffers
• optional reads allow for prefetching, and the device driver can decide whether prefetching is a good idea (e.g. not beyond the end of a track)

Partition Table

• a partition table for the x86 is a list of 4 partition entries at offset 446 (x1BE) in the first (boot) sector of a disk
• each partition entry has a 16 bytes of data (the last 2 bytes of the first sector hold the magic number 55AA, line 11571)
• the first 8 bytes include flags (e.g. 0x80 for a bootable disk) and geometry (heads, sectors, cylinders)
• the final 8 bytes are two 4-byte numbers recording the linear number of the start and size of the partition, in sectors
• partitions may be nested, e.g. the first partition may have another partition table in its first sector