CS 111 Notes January 16, 2008

OS Organizations

What are our goals?

Portability
Reliability and Robustness - predictable, handles new things well
Modularity - Flexibility, simplicity
Supports user applications
Performance - should be fast
Utilization - handling multiple loads, keeping computer as busy as possible

(occasionally utilization and performance conflict, but not usually)

How will the OS do all of this?

Virtualization!

The kernel has fill privileges while the applications have controlled access to the hardware (usually through the kernel)(figure 1

Figure 1: Applications must go through the kernel

When designing the kernel, we have to figure out how we want to control access to each piece of hardware.

ALU:

There are no real restrictions on computations (it would slow things down). Applications have full access (with few exceptions)

Time:

It is worth noting that the OS must also deal with time, such as controlling processes that may be stuck in an infinite loop or idle processes. This means that we cannot give a process complete control.

Memory:

An application should only have access to memory belonging to that application. We don't, however, want to use system calls to accomplish this because it would be far too slow.
In order to do this, the computer uses address translation. This means that each process "thinks" that it has its own memory starting at, say, 0x00000000. On the actual memory this is not the case (figure 2). Each address is translated by the hardware to a different location on the physical memory. This prevents individual apps from having access to any memory other than that which is allocated to it.
In the hardware there is a register called the "page register" that says which translation to use. This same register can tell a process that it cannot access certain locations in memory (called a page fault).

Figure 2: Virtual memory

Registers:

Registers are divided by the privilege level required in order to use them. The general purpose registers can be used by any programs, while there are some registers that are reserved for the kernel. When we have to deal with multiple processes, how will this work? Each application thinks that it has its own set of registers, but there is only one set on the CPU. This means that when the OS switches processes, it must save the current state of the old process (in a place in memory, this is called the "process descriptor") before giving the registers over to the new process. There is a specific location in memory called the "process descriptor table" which houses all of the process descriptors (see figure 3 and 4).

Figure 3: Process descriptors

Figure 4: Process descriptor table

When an interrupt occurs:

A few registers are saved: A goto (the location specified by the interrupt descriptor)
Privilege level becomes kernel
Copy saved registers to process descriptors
Load registers from a different process descriptor

This leads us to an important point regarding the number of registers that a system should have. On the one hand, it seems like a great idea to have lots and lots of them, it would be faster and easier on the compilers. There is a downside that would occur when switching processes though, all of these registers would have to be saved, causing hang and extra memory usage (keep in mind that registers have to be swapped at each system call since the kernel must take over). There are a few possible solutions to this issue:

Keep track of the registers used by each process and don't save those that are unused.
Make kernel not use certain registers, those registers need not be saved at syscalls... assuming we resume the same process
Hardware support for swapping out registers using privileged instructions

Access to I/O:

I/O devices require a different access strategy than the previously considered components because they are much slower. As many as 20 million instructions can be executed in a processor while awaiting the results of reading a single random sector off a hard drive. Also, since many I/O devices are used for permanent storage, robustness is a major factor. The lack of standardization in device interfaces can also create a problem which we would like to abstract away from the user to allow more portable access to peripherals. Because of these factors, system calls are an appropriate way to implement device access functions because they can be executed almost entirely in the kernel.

Before considering the appropriate interface for devices, it is important to partition them into their two main categories and consider the properties of each.

Disk Family

responds to requests – programs request data from the disk and wait for a response
finite capacity – the disk will eventually fill up
random access – programs may request data from anywhere on the disk

Network devices, keyboard, mouse, other input devices

responds to events – data is generated spontaneously, such as a keystroke or an incoming network packet
no limit to the amount of data supplied
data stream – the data supplied by these devices can only be accessed when they occur, not before or after

There are also other types of devices (such as the display), but we will focus on these two generic types of devices.

File Descriptors

Figure 5: File descriptors

There are many ways to implement device access, but we will focus on the strategy adopted by UNIX. In order to simplify the issues of device access, UNIX has a common interface for all I/O devices. All devices and the data on them is described by the file descriptor type and accessed with the same API.

The file descriptor consists of an integer number as a file handle and an offset, which points to the specific location within the file that the next read or write will come from.

ssize_t read(int fd, void* addr, size_t size);
- returns the number of bytes read off the disk, 0 if it reached the end of file (EOF), or -1 for error
- fd – file descriptor, represented as an integer
- size – number of bytes to read
off_t lseek(int fd, off_t offset, int whence);
- returns the new offset
- whence indicates what the offset is relative to:
  - SEEK_SET – relative to the start of the file
  - SEEK_CUR – relative to the current offset
  - SEEK_END – relative to the end of the file

The process of making a disk access system call generally proceeds like the following:

user process issues system call

Example: read(5, 0x7fff000, 512);
Note that the memory address specified in the read call is actually a virtual address, which gets translated by the kernel before access

the kernel takes over, examines the calling process's registers and memory, and determines the appropriate type of system call to make
kernel consults File Descriptor Table within the process descriptor

Note that the File Descriptor Table is another field in the process descriptor. This consists of an array of file descriptors indicating which files that process is currently reading from or writing to.

In order to open a file descriptor, a process must make the system call

int open( const char* location, int access_flags, ...);
- returns the file descriptor table index of the opened file, or -1 on error. The cause of the error can be determined by checking the global variable errno.
- access_flags – integer mask specifying the type of access the process wishes to have to the file:
  - O_RDONLY- read-only access
  - O_RDWR- read and write access
  - O_WRONLY – write-only access
- trailing arguments are variable, and depend on the value of the flags

When a process is finished with a file, it must close it in order to prevent a file descriptor leak. The system call to close a file descriptor is as follows:

int close(int fd);
- returns 0 for success. Returns -1 on error and setts errno appropriately.
- The following code segments will produce errors:
  - close(-1); - This will fail because -1 is not a valid file descriptor. Calling close with an argument larger than the number of file descriptors or an invalid file descriptor will have the same result.
  - close(0); close(0); - The second call will fail because the file has already been closed.
- If access to the file was buffered through the operating system rather than actually going to disk, errno will have the value EIO

Because of the high frequency of errors that can arise when writing to a disk, it is important to always check for errors after system calls.