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?