answers.txt

Name: Minhan Xia
UCLA ID: 204000665
Collaborators: Zhiyang Wang  303991529


-------------------------------------------------------------------------------

Response to Exercise 1:
We think it doesn't matter if we change run to schedule, since when the system turns into the kernal mode, its registers are stored in its own stack and the kernal put the return value (pid) on to the related space in process's stack. Even then the system switch to other process, the origin process's stack has not been modified. Later, when the origin process get scheduled, the system pop the registers' value from stack back to the registers and so we can still get the right pid.

One exceptional case is that if the system doesn't provide process memory isolation (mainly by virtual address), which is the case in weensyos, one process could still access to another process's memory. Then it's possible for another process to modify origin process's stack. In this case getpid in scheduling case will get the wrong answer.




Anything else you'd like us to know:

#2
One of the major problems here is for fork() to return 0 to the child process and return the pid of the child process to the parent process. We solve this by assign 0 directly to the eax register of the child process.

#3
I added a wait_pid field into the process descriptor to indicate the process id that the current process is waiting for. The value is -1 if the current process is not waiting for any other process. If a process enter wait(), its state will be set to BLOCKED and wait_pid will indicate which process it is waiting for.

Also, schedule() will look into BLOCKED processes. If the process that a BLOCKED process waiting for has exited, then schedule() will run the BLOCKED process.

#4 
The main problem that cause the bug is that in current code, it will never "terminate" a exited process even if the process waiting for it has get the return value. 

So, as defined that one process can only be waited by one other process, as if one process gets the return value, it will now terminate the zombie process by setting the status from zombie to empty. So that later on the process's resource could be utlized again.

Extra credit exercises:
We define EXTRA on the top of mpos-app.c and mpos-app2.c to make switching on and off more convenient.


#6 
My idea is to find an empty process descriptor and initialize the process descriptor using special_registers_init(). Then I make the stack pointer (esp) points to the top and instruction pointer (eip) points the address of function (void (*start_function)(void)). The function itself will yield() and return to kernel mode for scheduling. 



#7 
Here's the assumption I've made:
1. one process cannot commit suicide 
2. if one process is killed by other, than it's exit value will be set as -1, as it's an unexpected exit.

So, in the implementation of system call kill, the kernel will now change the target process's status to zombie and set the exit status value as -1. If the process has already been zombie, then the exit status value will not be changed.

And in app2, I change the code that now if a process with even number pid is created, it will attempt to kill all odd number processes.