1.4.3: I/O Devices

Show a real disk opened up and illustrate the components

• Platter
• Surface
• Head
• Track
• Sector
• Cylinder
• Seek time
• Rotational latency
• Transfer time

Devices are often quite complicated to manage and a separate computer, called a controller, is used to translate simple commands (read sector 123456) into what the device requires (read cylinder 321, head 6, sector 765). Actually the controller does considerably more, e.g. calculates a checksum for error detection.

How does the OS know when the I/O is complete?

1. It can busy wait constantly asking the controller if the I/O is complete. This is the easiest (by far) but has low performance. It is also called polling or PIO (Programmed I/O).
2. It can tell the controller to start the I/O and then switch to other tasks. The controller must then interrupt the OS when the I/O is done. Less waiting, but harder (concurrency!).
3. Some controllers can do DMA (Direct Memory Access) in which case they deal directly with memory after being started by the CPU. This takes work from the CPU and halves the number of bus accesses.

1.4.3: Buses

I don't care so much about the names of the buses, but the diagram given in the book doesn't show a modern design. The one on the right does.

1.5: Operating System Concepts

This will be very brief. Much of the rest of the course will consist in ``filling in the details''.

1.5.1: Processes

A program in execution. If you run the same program twice, you have created two processes. For example if you have two editors running in two windows, each instance of the editor is a separate process.

Often one distinguishes the state or context (memory image, open files) from the thread of control. Then if one has many threads running in the same task, the result is a ``multithreaded processes''.

The OS keeps information about all processes in the process table. Indeed, the OS views the process as the entry. This is an example of an active entity being viewed as a data structure (cf. discrete event simulations). An observation made by Finkel in his (out of print) OS textbook.

The set of processes forms a tree via the fork system call. The forker is the parent of the forkee, which is called a child. If the system blocks the parent until the child finishes, the ``tree'' is quite simple, just a line. But the parent (in many OSes) is free to continue executing and in particular is free to fork again producing another child.

A process can send a signal to another process to cause the latter to execute a predefined function (the signal handler). This can be tricky to program since the programmer does not know when in his ``main'' program the signal handler will be invoked.

Each user is assigned User IDentification (UID) and all processes created by that user have this UID. One UID is special (the superuser or administratore) and has extra privileges. A child has the same UID as its parent. It is sometimes possible to change the UID of a running process. A group of users can be formed and given a Group IDentification, GID.

Access to files and devices can be limited to a given UID or GID.

1.5.2: Deadlocks

A set of processes each of which is blocked by a process in the set. The automotive equivalent, shown at right, is gridlock.

1.5.3: Memory Management

Each process requires memory. The loader produces a load module that assumes the process is loaded at location 0. The operating system ensures that the processes are actually given disjoint memory. Current operating systems permit each process to be given more (virtual) memory than the total amount of (real) memory on the machine.

1.5.4: Input/Output

There are a wide variety of I/O devices that the OS must manage. For example, if two processes are printing at the same time, the OS must not interleave the output. The OS contains device specific code (drivers) for each device as well as device-independent I/O code.

1.5.5: Files

Modern systems have a hierarchy of files. A file system tree.

• In MSDOS the hierarchy is a forest not a tree. There is no file, or directory that is an ancestor of both a:\ and c:\.
• In unix the existence of (hard) links weakens the tree to a DAG.
• Unix also has symbolic links, which when used indiscriminately, permit directed cycles (i.e., the result is not a DAG).

You can name a file via an absolute path starting at the root directory or via a relative path starting at the current working directory.

In addition to regular files and directories, Unix also uses the file system namespace for devices (called special files, which are typically found in the /dev directory. Often utilities that are normally applied to (ordinary) files can be applied as well to some special files. For example, when you are accessing a unix system using a mouse and do not have anything serious going on (e.g., right after you log in), type the following command

    cat /dev/mouse

Before a file can be accessed, it must be opened and a file descriptor obtained. Many systems have standard files that are automatically made available to a process upon startup. These (initial) file descriptors are fixed

• standard input: fd=0
• standard output: fd=1
• standard error: fd=2

A convenience offered by some command interpretors is a pipe or pipeline. The pipeline

  dir | wc

1.5.6: Security

Files and directories normally have permissions

• Normally have at least rwx.
• User, group, world
• A more general mechanism is an access control lists.
• Often files have ``attributes'' as well. For example the linux ext2 file system supports a ``d'' attribute that is a hint to the dump program not to backup this file.
• When a file is opened, permissions are checked and, if the open is permitted, a file descriptor is returned that is used for subsequent operations

1.5.7: The Shell or Command Interpreter (DOS Prompt)

The command line interface to the operating system. The shell permits the user to

• Invoke commands
• Pass arguments to the commands
• Redirect the output of a command to a file or device
• Pipe one command to another (as illustrated above via ls | wc)

Homework: 8