Wordsmithing.
[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 reading and writing user data from the kernel.
63
64 >> Suppose a system call causes a full page (4,096 bytes) of data to be
65 >> copied from user space into the kernel.  What is the least and the
66 >> greatest possible number of inspections of the page table (e.g. calls
67 >> to pagedir_get_page()) that might result?  What about for a system
68 >> call that only copies 2 bytes of data?  Is there room for improvement
69 >> in these numbers, and how much?
70
71 >> Briefly describe your implementation of the "wait" system call and how
72 >> it interacts with process termination.
73
74 >> Any access to user program memory at a user-specified address can fail
75 >> due to a bad pointer value.  Such accesses must cause the process to
76 >> be terminated.  System calls are fraught with such accesses, e.g. a
77 >> "write" system call requires reading the system call number from the
78 >> user stack, then each of the call's three arguments, then an arbitrary
79 >> amount of user memory, and any of these can fail at any point.  This
80 >> poses a design and error-handling problem: how do you best avoid
81 >> obscuring the primary function of code in a morass of error-handling?
82 >> Furthermore, when an error is detected, how do you ensure that all
83 >> temporarily allocated resources (locks, buffers, etc.) are freed?  In
84 >> a few paragraphs, describe the strategy or strategies you adopted for
85 >> managing these issues.  Give an example.
86
87 ---- SYNCHRONIZATION ----
88
89 >> The "exec" system call returns -1 if loading the new executable fails,
90 >> so it cannot return before the new executable has completed loading.
91 >> How does your code ensure this?  How is the load success/failure
92 >> status passed back to the thread that calls "exec"?
93
94 >> Consider parent process P with child process C.  How do you ensure
95 >> proper synchronization and avoid race conditions when P calls wait(C)
96 >> before C exits?  After C exits?  How do you ensure that all resources
97 >> are freed in each case?  How about when P terminates without waiting,
98 >> before C exits?  After C exits?  Are there any special cases?
99
100 ---- RATIONALE ----
101
102 >> Why did you choose to implement access to user memory from the
103 >> kernel in the way that you did?
104
105 >> What advantages or disadvantages can you see to your design for file
106 >> descriptors?
107
108 >> The default tid_t to pid_t mapping is the identity mapping.  If you
109 >> changed it, what advantages are there to your approach?
110
111                            SURVEY QUESTIONS
112                            ================
113
114 Answering these questions is optional, but it will help us improve the
115 course in future quarters.  Feel free to tell us anything you
116 want--these questions are just to spur your thoughts.  You may also
117 choose to respond anonymously in the course evaluations at the end of
118 the quarter.
119
120 >> In your opinion, was this assignment, or any one of the three problems
121 >> in it, too easy or too hard?  Did it take too long or too little time?
122
123 >> Did you find that working on a particular part of the assignment gave
124 >> you greater insight into some aspect of OS design?
125
126 >> Is there some particular fact or hint we should give students in
127 >> future quarters to help them solve the problems?  Conversely, did you
128 >> find any of our guidance to be misleading?
129
130 >> Do you have any suggestions for the TAs to more effectively assist
131 >> students, either for future quarters or the remaining projects?
132
133 >> Any other comments?