1 files changed, 137 insertions, 0 deletions

diff --git a/proj2.txt b/proj2.txt
new file mode 100644
index 0000000..5405336
--- /dev/null
+++ b/proj2.txt
@@ -0,0 +1,137 @@
+                +---------------------------+
+                |         ProgOS            |
+                | PROJECT 2: VIRTUAL MEMORY |
+                |         DESIGN DOCUMENT   |
+                +---------------------------+
+
+---- GROUP ----
+
+>> Fill in the names and email addresses of your group members.
+
+Peter Ketscher <e9651415@mail.student.tuwien.ac.at>
+Karoline Knoth <e0326266@student.tuwien.ac.at>
+Manuel Mausz <manuel-uni@mausz.at>
+
+---- PRELIMINARIES ----
+
+>> If you have any preliminary comments on your submission, notes for the
+>> TAs, or extra credit, please give them here.
+
+>> Please cite any offline or online sources you consulted while
+>> preparing your submission, other than the Pintos documentation, course
+>> text, lecture notes, and course staff.
+
+                  PAGE TABLE MANAGEMENT
+                  =====================
+---- DATA STRUCTURES ----
+
+>> A1: Copy here the declaration of each new or changed `struct' or
+>> `struct' member, global or static variable, `typedef', or
+>> enumeration.  Identify the purpose of each in 25 words or less.
+
+struct thread:
+  struct hash page_table ...page table of thread
+
+struct page_table_entry:
+  void *upage             ...virtual address of page
+  bool loaded             ...indicates if page is loaded
+  enum type               ...type of page
+  union struct segment    ...structure needed for lazy loading of data segments
+  struct hash_elem elem   ...Hash element.
+
+---- IMPLEMENTATION ----
+>> A2: Describe how you implemented lazy page loading. How do you
+>> determine the file and file offset corresponding to a virtual
+>> address?
+
+TODO
+
+---- SYNCHRONIZATION ----
+>> A3: How do you deal with or prevent page faults in file system
+>> routines. Argue why your solution is deadlock free.
+
+TODO
+
+                      STACK GROWTH
+                      ============
+
+---- DATA STRUCTURES ----
+
+>> B1: Copy here the declaration of each new or changed `struct' or
+>> `struct' member, global or static variable, `typedef', or
+>> enumeration.  Identify the purpose of each in 25 words or less.
+
+extern void *syscall_sp   ...stored stack pointer for the "page fault inside
+                             syscall/kernel"-case
+
+---- IMPLEMENTATION ----
+>> B2: Describe how you integrated the (potentially growing) stack segment
+>> into your page table management implementation.
+
+TODO
+
+---- ALGORITHMS ----
+>> B3: Explain how you detect a page fault which should trigger a
+>> stack growth. What asssumptions are needed for your implementation
+>> to work?
+
+TODO
+
+                   MEMORY MAPPED FILES
+                   ===================
+
+---- DATA STRUCTURES ----
+
+>> C1: Copy here the declaration of each new or changed `struct' or
+>> `struct' member, global or static variable, `typedef', or
+>> enumeration.  Identify the purpose of each in 25 words or less.
+
+struct page_table_entry:
+  union struct TODO       ...structure needed for loading of memory mapped files
+
+---- ALGORITHMS ----
+
+>> C2: Describe how memory mapped files integrate into your virtual
+>> memory subsystem.
+
+TODO
+
+>> C3: Explain how you determine whether a new file mapping overlaps
+>> any existing segment.
+
+TODO
+
+---- RATIONALE ----
+
+>> C4: Mappings created with "mmap" have similar semantics to those of
+>> data demand-paged from executables, except that "mmap" mappings are
+>> written back to their original files, not to swap.  This implies
+>> that much of their implementation can be shared.  Explain why your
+>> implementation either does or does not share much of the code for
+>> the two situations.
+
+TODO
+
+                     SURVEY QUESTIONS
+                     ================
+
+Answering these questions is optional, but it will help us improve the
+course in future quarters.  Feel free to tell us anything you
+want--these questions are just to spur your thoughts.  You may also
+choose to respond anonymously in the course evaluations at the end of
+the quarter.
+
+>> In your opinion, was this assignment, or any one of the three problems
+>> in it, too easy or too hard?  Did it take too long or too little time?
+
+>> Did you find that working on a particular part of the assignment gave
+>> you greater insight into some aspect of OS design?
+
+>> Is there some particular fact or hint we should give students in
+>> future quarters to help them solve the problems?  Conversely, did you
+>> find any of our guidance to be misleading?
+
+>> Do you have any suggestions for the TAs to more effectively assist
+>> students, either for future quarters or the remaining projects?
+
+>> Any other comments?