Lecture 1 Scribe Notes

Date: April 4th, 06
CS 111
Professor: Eddie Kohler, kohler@cs.ucla.edu
OH: M 10-11, BH 4531C
TAs: Chris Frost, Mike Mammarella

Works:

Labs: 4 Linux-based programming labs.
- Each team is expected to do one challenge problem in one of the labs in the quarter.
- A challenge problem is one where you go "above and beyond the call of duty" and add to the functionality of the project. You will be expected to give a presentation in discussion section on the challenge problem you have addressed
Tests: 1 midterm and 1 final
Homework:
- mini-labs (3 or 4)
- scribe notes: groups of 4
- short reports: 1 page writing assignments on current topics
- class participation

Note: The lab, test, and homework sections are worth about 1/3 of the overall grade each. 
      There are extra credits in labs and mini-labs

Academic honesty: the code and text is your own. You may talk to whomever you want, but you need to credit them. We’re using turnitin.com. You must sign the policy handout in order to have any of your work graded. The only time when you can share code in this class is with your partner on labs.

Late policy: 3 free late days – you can extend assignments by a total of three days with no penalty. If you exceed 3 late days, then you are graded down one letter grade per day. If group uses late day it applies to both lab partners. Late days must be used in units of one full day. There is no need to inform the TA's or Professor when you plan on using these late days. They will decide where to use them for you once all of your assignments have been submitted.

PTE’s and waiting list: everybody on the waitlist will probably get into the class

Operating systems

What is an operating system?

There are many ways to describe an operating system such as:

Software that enables users to interact with input and output devices, which are called physical I/O devices. Examples of input devices include a mouse and keyboard and examples of output devices include computer monitors and speakers.
Software that is responsible for allocating computer resources. Examples of computer resources that can be allocated include memory and disk space.
Software that schedules access to the processor among different processes. This is an important part of the operating system because many different processes want access to the processor at the same time, yet the processor can only work on one process at a time.
Software that provides interfaces between applications and hardware. If each application had to utilize the low-level commands of every piece of hardware that it had to use, writing an application would be very much harder and much more time consuming than it currently is. Thus an operating system provides the abstractions necessary to make the production of applications more efficient.

Some examples of operating systems include Windows, Mac OS X, Linux, Solaris, and BSD. In this course, we will concentrate in Linux. Why is the class taught focusing on Linux? There are two important reasons for this. The first one is that Linux is an open source operating system, so we can easily modify and extend it. The second reason is that Linux is a version of UNIX, which is the source of modern operating systems' core ideas.

Official definition: an operating system is software that provides programs with access to an abstract machine.

It allows programs to communicate with HW and with each other.

An abstract machine is a virtual/abstraction of: I/O devices, memory, and CPU time.

We abstract the machine in order to provide two goals: protection and sharing.
- Protection: two programs can’t hurt one another.
- Sharing: two programs can share hardware.

Why do we need an operating system?
One of the reasons that an operating system is useful is because it provides protection. It serves as an abstraction layer between the software and hardware. This prevents damage to the computer hardware, by allowing the operating system to monitor and interact with the hardware directly in a privileged mode, rather than allow potentially malicious programs to interact with the hardware. Another reason why we need the protection provided by an operating system is to control the allocation of memory to different programs. Without an operating system, one program can write into another program’s memory.
Examples on why we need protection:

Segmentation fault: OS ensures program’s memory spaces are isolated. Without an OS, the program might crash the machine, rather than simply throwing a segmentation fault. The OS's fault and trap handler allows the user to diagnose software problems and prevents the software problems from developing into hardware problems.
Buffer overflow: programming mistake that can be exploited by viruses and other bad code. The only thing that can prevent this exploitation is an operating system.
HSC: halt and spontaneously combust. This is a processor instruction included in the MIPS-X. It causes the processor to stop and spontaneously combust. Obviously, this instruction should not be accessible to most programs. Thus we need an operating system to provide an abstract machine that will prevent user-level programs from having access to such instructions.
In the Motorola 6800 processor there’s an instruction that toggles the bus wires (this is a test instruction).
This can be used to actually burn out the parts of the system associated with these wires. Thus, just like for the HSC instruction above, we need an operating system to protect the hardware from malicious software.
Software used to be used to control an electron gun.
If the software is caught in an infinite loop, it can burn out the screen. Thus even when there are no evil intentions from programs, we need to have the operating system provide hardware protection.
The OS ensures safety by preventing programs from executing unsafe instructions on the CPU, or unsafe hardware commands.

Example of a code that causes Segmentation Fault:

Note: This program tries to write the value 5 to the memory address 394. We don’t know what is at 
      address 394. This is also a protection violation because it writes into a random location in 
      memory that is not associated with our program.

int main(int c, char **v) {
  int *x = (int *) 394;
  *x = 5;
}

OS ensure safety by preventing programs from executing unsafe instructions on CPU and unsafe hardware commands.
OS systems allow us to diagnose software bugs by catching segmentation faults.

Another reason to have an operating system is sharing: in order to run 10 programs simultaneously, it would be a shame if we required 10 hard drives and 10 processors. The abstraction layer provided by the operating system allows programs to act as if they are the only process running on a machine, when in reality they may be sharing many resources.

How do we evaluate an OS mechanism to be useful and effective?

There are many different aspects one should consider when evaluating an extension to an operating system.

First, the operating system should be generic, so that it is compatible with multiple different hardware implementations.

For example, UNIX's file system mechanism does not provide direct access to the storage devices and disks. Instead, it provides access to a generic storage units known as files. It further abstracts the hardware implementation by allowing the user to access the mouse, keyboard, and other controllers through files. Instead of requiring the programmer to use complicated hardware access methods, it simply requires the programmer to write to or read from a system file on the UNIX file system. The UNIX operating system then translates these reads and writes into hardware-specific commands. This is an example of an OS mechanism that is general, rather than specific and constraining; for example, the OS can translate many different mouse device protocols into a common file-based interface.

Second, a good operating system mechanism will support as many different kinds of programs as possible. In other words, it provides access to common routines used by software programs through static and dynamic libraries.

Finally, a good OS mechanism provides performance, robustness, and neutrality.

Performance: allows a program to use all of the power of the hardware.
Robustness: programs are insulated from faults. These goals are sometimes in conflict. For example, let’s say a computer has two disks. In order to achieve best performance we can make a single virtual disk whose size is equivalent to the combined size of the two real disks. In order to achieve robustness we can have one disk contain a copy of the contents of the other disk.
Neutrality: the interface is general, not specialized.
1. For example, the interfaces in the OS inside of a PlayStation are specialized because they are designed to best suit game programmers. Thus the OS inside of a PlayStation would be considered to have poor neutrality.

Why study operating systems?

Why study computer science? We can use computers as people to allow us to do more and better things. Computers make us smarter (democratizing force). Computer science gives us some insight on how computers can make us smarter. Programming is how that works. OS teaches programming because OS as a program deals with those issues deeper and harder.

File abstraction:

A file is a persistent storage unit, composed of a sequence of bytes. In Unix's file stream model, the interface allows writing and reading arbitrary numbers of bytes, as well as seek (move ahead in the sequence, or in other words change the cursor position in the file).

Before the file stream model, some operating systems supported two different file models, with different limitations. The first was a sequential file model that supported read and write, but not seek. The second was a random access records model that could only read 1 record, write 1 record, and seek to a record position; each record would be something such as a punch card that was 64 bytes in size or more. This pair of models had a number of drawbacks. What about reading more than one record at a time? What about seeking to an arbitrary position in a sequential file (which can be very useful for compressed files, for example)? There were technical reasons for this division, nothing fundamental.

The OS mechanism of the i-node (which we'll see in a couple weeks) led to the simpler file stream model, with arbitrary read/write amounts (not fixed records) PLUS seeking. This improved the abstract machine, which made it easier to write good programs.

Mouse Polling:
Now, say for example we had a virtual button on the screen, such as the following button:

This button was borrowed from Mozilla Firefox's options panel using print screen

We would like to have an image of a kitty pop up on the screen when we click on the virtual button with our mouse. How do we accomplish this? For now, we will focus on the first part, which is finding out when the mouse button has been clicked so that we can take the appropriate action.

One possibility of how a program can interact with a mouse is described by the following example. This example utilizes an approach called polling. The reason for the name polling is that the program contains an infinite loop that continuously checks to see if some event has occurred.

For this example, we assume that the program has the following interface to the mouse:
Whenever the mouse button is pressed, a 1 will automatically be written to memory address 0.

The code for this example is as follows:

while (*((char *) 0) == 0)   //mouse button is up 
    /* do nothing */;

There are many problems with such an interface to the mouse and the resulting application that tries to utilize it. They include:

The fact that we might miss a mouse click. This will happen if the mouse happens to be clicked in between the times when the mouse button status is being checked.
Busy waiting. This is a term that describes the actions of a program that implements polling. In this case, the event that we are checking for is the mouse being clicked. This is wasteful because the CPU will do nothing except for continuously check until the mouse is clicked. If some other type of interface to the mouse had been used, then the CPU would be able to work on another process until the mouse had been clicked, instead of wasting time continuously checking.
The mouse button is shared poorly. This interface does not provide some information to us such as where on the screen the click occurs. What if a click occurred but it was on another virtual button that had no relation to this program? We would still break out of the loop and assume that the click had occurred on our virtual button. Clearly, this would cause many problems

This interface to the mouse is an example of DMA (direct memory access). The biggest problem with DMA is that OS’s have to avoid busy waiting. Although we have severely criticized DMA here, it is very useful in some other applications. Some information on the proper use of DMA can be found at Wikipedia's explanation of DMA.

Fun Links:

The following is a link to the Wikipedia explanation of the MIPS-X processor which provides further links to the programmer's manual

Wikipedia MIPS-X Information

The following is a link to a news article that provides some information on Sony's API and its possible changes. It shows how the API is proprietary and specifically designed to benefit game programming.

PlayStation News Article