Make tests public. Rewrite most tests. Add tests.
[pintos-anon] / doc / userprog.tmpl
1                      +--------------------------+
2                      |          CS 140          |
3                      | PROJECT 2: USER PROGRAMS |
4                      |     DESIGN DOCUMENT      |
5                      +--------------------------+
6
7 ---- GROUP ----
8
9 >> Fill in the names and email addresses of your group members.
10
11 FirstName LastName <email@domain.example>
12 FirstName LastName <email@domain.example>
13 FirstName LastName <email@domain.example>
14
15 ---- PRELIMINARIES ----
16
17 >> If you have any preliminary comments on your submission, notes for the
18 >> TAs, or extra credit, please give them here.
19
20 >> Please cite any offline or online sources you consulted while
21 >> preparing your submission, other than the Pintos documentation, course
22 >> text, and lecture notes.
23
24                            ARGUMENT PASSING
25                            ================
26
27 ---- DATA STRUCTURES ----
28
29 >> Copy here the declaration of each new or changed `struct' or `struct'
30 >> member, global or static variable, `typedef', or enumeration.
31 >> Identify the purpose of each in 25 words or less.
32
33 ---- ALGORITHMS ----
34
35 >> Briefly describe how you implemented argument parsing.  How do you
36 >> arrange for the elements of argv[] to be in the right order?  How do
37 >> you avoid overflowing the stack page?
38
39 ---- RATIONALE ----
40
41 >> Why does Pintos implement strtok_r() but not strtok()?
42
43 >> In Pintos, the kernel separates commands into a executable name and
44 >> arguments.  In Unix-like systems, the shell does this separation.
45 >> Identify at least two advantages of the Unix approach.
46
47                              SYSTEM CALLS
48                              ============
49
50 ---- DATA STRUCTURES ----
51
52 >> Copy here the declaration of each new or changed `struct' or `struct'
53 >> member, global or static variable, `typedef', or enumeration.
54 >> Identify the purpose of each in 25 words or less.
55
56 >> Describe how file descriptors are associated with open files.  Are
57 >> file descriptors unique within the entire OS or just within a single
58 >> process?
59
60 ---- ALGORITHMS ----
61
62 >> Describe your code for copying data from user programs into the kernel
63 >> and vice versa.
64
65 >> Suppose a system call causes a full page (4,096 bytes) of data to be
66 >> copied from user space into the kernel.  What is the least and the
67 >> greatest possible number of inspections of the page table (e.g. calls
68 >> to pagedir_get_page()) that might result?  What about for a system
69 >> call that only copies 2 bytes of data?  Is there room for improvement
70 >> in these numbers, and how much?
71
72 >> Briefly describe your implementation of the "wait" system call and how
73 >> it interacts with process termination.
74
75 >> Any access to user program memory at a user-specified address can fail
76 >> due to a bad pointer value.  Such accesses must cause the process to
77 >> be terminated.  System calls are fraught with such accesses, e.g. a
78 >> "write" system call requires reading the system call number from the
79 >> user stack, then each of the call's three arguments, then an arbitrary
80 >> amount of user memory, and any of these can fail at any point.  This
81 >> poses a design and error-handling problem: how do you best avoid
82 >> obscuring the primary function of code in a morass of error-handling?
83 >> Furthermore, when an error is detected, how do you ensure that all
84 >> temporarily allocated resources (locks, buffers, etc.) are freed?  In
85 >> a few paragraphs, describe the strategy or strategies you adopted for
86 >> managing these issues.  Give an example.
87
88 ---- SYNCHRONIZATION ----
89
90 >> The "exec" system call returns -1 if loading the new executable fails,
91 >> so it cannot return before the new executable has completed loading.
92 >> How does your code ensure this?  How is the load success/failure
93 >> status passed back to the thread that calls "exec"?
94
95 >> Consider parent process P with child process C.  How do you ensure
96 >> proper synchronization and avoid race conditions when P calls wait(C)
97 >> before C exits?  After C exits?  How do you ensure that all resources
98 >> are freed in each case?  How about when P terminates without waiting,
99 >> before C exits?  After C exits?  Are there any special cases?
100
101 ---- RATIONALE ----
102
103 >> Why did you choose to implement user-to-kernel copying the way you
104 >> did?
105
106 >> What advantages or disadvantages can you see to your design for file
107 >> descriptors?
108
109 >> The default tid_t to pid_t mapping is the identity mapping.  If you
110 >> changed it, what advantages are there to your approach?
111
112                            SURVEY QUESTIONS
113                            ================
114
115 Answering these questions is optional, but it will help us improve the
116 course in future quarters.  Feel free to tell us anything you
117 want--these questions are just to spur your thoughts.  You may also
118 choose to respond anonymously in the course evaluations at the end of
119 the quarter.
120
121 >> In your opinion, was this assignment, or any one of the three problems
122 >> in it, too easy or too hard?  Did it take too long or too little time?
123
124 >> Did you find that working on a particular part of the assignment gave
125 >> you greater insight into some aspect of OS design?
126
127 >> Is there some particular fact or hint we should give students in
128 >> future quarters to help them solve the problems?  Conversely, did you
129 >> find any of our guidance to be misleading?
130
131 >> Do you have any suggestions for the TAs to more effectively assist
132 >> students, either for future quarters or the remaining projects?
133
134 >> Any other comments?