Operating Systems 2014F Lecture 3

Audio from the lecture given on September 12, 2014 is now available.

Process API

Highly orthogonal - not only one way of doing things. Concept of Symbolic links, vs. hard links in Unix. In windows, there are about 5 different versions of links, and some of them work on some versions of windows. It's a complete mess.

They first introduced 1 api, that turned out to be bad w/ limited functionality. Evolution of windows - you look at their API and you get a mess.

ioctl - system call in unix / linux systems -an abomination - it doesnt' have well defined semantics - io control you give it the number of a device, and some arguments, and it varies from device to device as to what it does. In unix that is the exception. Most of the base stuff is clean. The people who worked at bell labs were smart, they created a system that they wanted to use for themselves.

In Unix, you don't call 1 call - you have 2 calls.

fork()

The classic structure of how to use fork:

if (fork()) {

} else {

}

Every call to fork returns two values. fork() always returns a process id and 0. After you call fork, you have two copies of your code running. What is in their memory? What files are open? - Exactly the same process, but you have two of them. That's why you always see a fork in a conditional, because you have 2 distinct processes running w/ exactly the same memory state, except for one difference:

if (pid=fork()) {
 // parent
} else {
 // child (pid = 0)
}

key role that init has to deal with are orphans. Child processes without a parent. When their parent is gone, init becomes their parent. There's something important about having a parent. Parents get the process id of the children. There is some kind of importance to the parent. What obligations unix places on parent processes. What is the use of a child to a parent. Why did you create a child? Multi CPU system - create another process, it can go off and do another computation on another cpu - doubles your power. But it's more than that. it can be used to do things that are potentially unsafe. Going to try parsing some file, that's been given to you by an untrusted source. If you do all of this stuff inside the main process, you can corrupt itself. There is a nuclear power plant - Star trek into darkness - whomever goes in there is going to die. Let the clone go in there, the unix solution to the kobayashi scenario. make a copy go in there.

Every process has a return value. Who gets it? The parent process. when your c program terminates, it gets a value, and that number goes to the parent process. You have to reap the child, you have to inspect it's remains and figure out what happened. If the process was orphaned, then it became a ward of the state, and init will collect the information, but it doesn't really care. This is important because unix expects someone to care about the dead.

fork bomb = keeps creating processes

while(1){ 
 fork();
}

There is a finite number of processes that you can have on a system. Why can root deal with this? When you are the superuser, you have a certain number of process slots that are allocated to you. You can create your own processes, and kill off the bad one. (Local DOS - Denial of Service attack)

execve(, , )

specific use cases for using both individually, without having to call both of them.

A system call is not a function call. Talking about mechanisms. What is a system call? What is a function?

context switch - switching between processes as part of a context switch there is something known as an upcall. I need to switch into a privileged mode. I can access disks directly. I have full control of the computer. I have to switch into that mode, where I have full control of the computer. Switching in and out, that's a context switch. That's up to the privileges of the kernel. This is not a function call.