Project 2: User Programs
You can find the official documentation for project 2 on Stanford's website.
1. Project Setup -
1.1 Keep Alarm Code:
You'll need to create a separate proj2 directory in the root directory of your repository. You will need alarm working for project 2, therefore you will need to setup using on of the two following ways:
1. Copy and paste the contents of pintos-base repository into the proj2 directory. Afterwards copy & paste your project 1 code for alarm.
2. Copy and paste the contents of proj1 directory into the proj2 directory. Afterwards remove all the priority donation code from project 1.
Once you have setup the proj2 directory, run make check from src/threads/build to see if you pass all the alarm tests (except alarm-priority since that is a priority-donation test.
2. The Process File -
In Pintos, every user program is run by a process. In a modern operating system, a single thread can run multiple processes; however in Pintos, every thread will only run one and only one process.
If you look in src/userprog/process.h, you will see a small handful of functions. These are the functions for user programs. The following is a short and incomplete description of each:
Function - Description
process_execute - Executes the user program from the designated file in the argument
process_wait - Waits for the child process with designated tid to finish before continuing execution
process_exit - Terminates user program currently running
process_activate - Sets up CPU to run user program in current thread
3 Part 1: Setup Stack -
In this part, you will take in a filename for a user program (a command line argument), parse it, and setup the stack for this user program.
You will be mainly working in src/userprog/process.c.
3.1 Where a User Program Starts:
If you read the description for process_execute, you will see that this is the function responsible to start a user program. Also, the argument passed into this function is a filename.
3.2 Emulate process_wait()
Looking at the file process.c, when a new process is created in process_execute, you will notice that the function thread_create is created. When a child process is created, the parent process will wait for this process to ?nish loading properly, then proceed to continue with its execution.
3.3 Setup Stack:
First notice that setup_stack only takes in a void** esp (the stack pointer). Feel free to add more arguments and pass in any other information you want.
Don't modify what's already there, you'll need to add on to the function before you return success. Remember void** esp will be initialized with PHYS_BASE, which is the top of the stack. You'll need to incrementally move the pointer and write data to the pointer. Also remember that since it's a stack, you'll want to write everything in reverse order, and you want to decrement the pointer instead.
Here are the general steps to setting up the stack. The code snippets will not actually work, but they are to give you a gist of how it's supposed to work.
1. Parse the filename deliminating by white spaces. Notice that setup_stack doesn't have access to the filename. You'll need to find a way to pass that information into this function. Parsing the filename can easily be done with strtok_r.
2. Write each argument (including the executable name) in reverse order, as well as in reverse for each string, to the stack. Remember to write a \0 for each argument. memcpy will come in handy here.
3. Write the necessary number of 0s to word-align to 4 bytes. A little modulus math and mem-set will get the job done.
4. Write the last argument, consisting of four bytes of 0's.
5. Write the addresses pointing to each of the arguments. You'll need to figure out how to reference the addresses after writing all the arguments. These are char*s.
6. Write the address of argv[0]. This will be a char**.
7. Write the number of arguments (argc). Make sure that this spans over 4 bytes.
8. Write a NULL pointer as the return address. This will be a void*.
It will be a good idea to use hex_dump to check the correctness of your stack after each and every step in order to avoid a debugging mess.
4. Syscall Handler -
Part 2 of the project will require you to implement the support for user programs to request system call functions (kernel functions). You will mainly be working in src/userprog/syscall.c and src/userprog/process.c. This section is written with reference to Colin Cammarano's guide from Spring of 2016.
Assignment Files - https://www.dropbox.com/s/6z9vhonc2j6biqr/Assignment%20Files.rar?dl=0