Reference no: EM131032391

Objectives

ASST2

After completing ASST2 you should:

1. Be able to write code that meets a speci?ed interface de?nition.

2. Understand how to represent processes in an operating system.

3. Have designed and implemented data structures to manage processes in an operating system.

4. Understand how to implement system calls.2. Assignment Organization
Your current OS/161 system has minimal support for running user binaries-nothing that could be considered a true process. ASST2 starts the transformation of OS/161 into a true multi-tasking operating system.

3. Design
Beginning with ASST2 your design documents become an important part of approaching each assignment.

A design document should clearly reflect the development of your solution, not merely explain what you programmed. If you try to code first and design later, or even if you design hastily and rush into coding, you will most certainly end up confused and frustrated. Don't do it! Work with your partner to plan everything you will do. Don't even think about coding until you can precisely explain to each other what problems you need to solve and how the pieces relate to each other.

3.1. Design Considerations

Here are some additional questions and thoughts to aid in writing your design document. They are not, by any means, meant to be a comprehensive list of all the issues you will want to consider.

You do not need to explicitly answer or discuss these questions in your executive summary, but you should at least think about them.

Your system must allow user programs to receive arguments from the command line. For example, you should be able to run the following program:

char *filename = "/bin/cp";
char *args[4];
pid_t pid;

args[0] = "cp";
args[1] = "file1";
args[2] = "file2"; args[3] = NULL;

pid = fork();

if (pid == 0) {
execv(filename, args);
}

The code snippet above loads the executable file /bin/cp, installs it as a new process, and executes it. The new process will then find file1 on the disk and copy it to file2.

Passing arguments from one user program, through the kernel, into another user program, is a bit of a chore. What form does this take in C? This is rather tricky, and there are many ways to be led astray. You will probably find that very detailed pictures and several walkthroughs will be most helpful. This piece of code, in particular, is impossible to write correctly without being carefully designed beforehand 3.

Some other questions to consider:

1. What primitive operations exist to support the transfer of data to and from kernel space? Do you want to implement more on top of these?

2. When implementing exec, how will you determine:

a. the stack pointer initial value

b. the initial register contents

c. the return value

d. whether you can execute the program at all?

3. You will need to bullet-proof the OS/161 kernel from user program errors. There should be nothing a user program can do-and we will try almost everything-to crash the operating system, with the exception of explicitly asking the system to halt.

4. What new data structures will you need to manage multiple processes?

5. What relationships do these new structures have with the rest of the system?

6. How will you manage file accesses? When the shell invokes the cat command, and the cat command starts to read file1, what will happen if another program also tries to read file1? What would you like to happen?

4. Code Reading

To help you get started designing, we have provided the following questions as a guide for reading through the code.

Questions to consider

1. What are the ELF magic numbers?

2. What is the difference between UIO_USERISPACE and UIO_USERSPACE? When should one use UIO_SYSSPACE instead?

3. Why can the struct uio that is used to read in a segment be allocated on the stack in load_segment? Or, put another way, where does the memory read actually go?

4. In runprogram why is it important to call vfs_close before going to user mode?

5. What function forces the processor to switch into user mode? Is this function machine dependent?

6. In what files are copyin, copyout, and memmove defined? Why are copyin and copyout necessary? (As opposed to just using memmove.)

7. What is the purpose of userptr_t?5. Implementation Implement system calls and exception handling.

6. Scheduling

7. Writing Your Own Tests

Part of ASST2 is learning to test your own code.

We provide comprehensive test programs that usually test multiple system calls at once. A consequence of this is that if even one of these system calls is unimplemented, then the whole test will likely fail.

You are encouraged to write your own tests which will help you debug specific system calls. You are also encouraged to look at /testbin/badcall and refer to the OS/161 man pages to ensure that you are handling all of the exceptions correctly.

ASST3: Virtual Memory

Objectives

After completing ASST3 you should:

1. Understand how to design a set of interfaces to implement a collection of functionality.

2. Be familiar with OS handling of TLB and page faults.

3. Possess a solid intuition about virtual memory and what it means to support it.

2. TLB Handling and Paging

To some degree, implementing virtual memory comes down to managing the TLB.

3. Code Reading

These should help refresh your memory a bit on the details of address translation and the types of memory-related faults.

4. Design

Create a design document for ASST3 similar to what you created for ASST2.

5. Implementation

Implement virtual memory and swapping.

To do this, you must

1. Implement the code that services TLB faults.

2. Add paging to your operating system.

3. Add the sbrk system call, so that the malloc library we provide works.

6. Grading

ASST3 grading is divided into three incremental parts, with a cumulative test161 target that tests different parts of your VM subsystem:

1. Coremap

2. Virtual Address Spaces

3. Swapping

You can download the Code file and assignment from this link:

https://www.dropbox.com/s/kxtotk7acu7abud/homework.zip?dl=0