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