answers to design doc of proj2

1 files changed, 28 insertions, 6 deletions

diff --git a/proj2.txt b/proj2.txt
index 5405336..3b89826 100644
--- a/proj2.txt
+++ b/proj2.txt
@@ -30,7 +30,7 @@ Manuel Mausz <manuel-uni@mausz.at>
 >> enumeration.  Identify the purpose of each in 25 words or less.
 
 struct thread:
-  struct hash page_table ...page table of thread
+  struct hash page_table ...supplemental page table of thread
 
 struct page_table_entry:
   void *upage             ...virtual address of page
@@ -44,13 +44,28 @@ struct page_table_entry:
 >> determine the file and file offset corresponding to a virtual
 >> address?
 
-TODO
+When we try to insert a new segment into our supplemental page table we record some information in the struct segment of each page table entry. This struct contains
+
+-) the virtual address of the page
+-) the type of the page table entry, weather it is an ordinary segment or a
+memory mapped file page
+-) if the page is already loaded or not (per default false)
+-) the file the page corresponds to
+-) the offset in the file
+-) if the page is writable or not
+
+Lazy loading of pages is accomplished by not loading the page instantly. The
+actual page-loading is done when a page-fault occurs.
+
 
 ---- SYNCHRONIZATION ----
 >> A3: How do you deal with or prevent page faults in file system
 >> routines. Argue why your solution is deadlock free.
 
-TODO
+As we do not have any global structures, that means they are per process and
+per thread, page faults can not happen, the same argument goes for the
+question of being deadlock free. File-structures are per process too, so only
+one process can deal with a file at once.
 
                       STACK GROWTH
                       ============
@@ -68,14 +83,21 @@ extern void *syscall_sp   ...stored stack pointer for the "page fault inside
 >> B2: Describe how you integrated the (potentially growing) stack segment
 >> into your page table management implementation.
 
-TODO
+The Stack growth itself is implemented in the page fault handler. The page
+table is just needed to allocate a new page for the stack when it needs to
+grow.
 
 ---- ALGORITHMS ----
 >> B3: Explain how you detect a page fault which should trigger a
->> stack growth. What asssumptions are needed for your implementation
+>> stack growth. What assumptions are needed for your implementation
 >> to work?
 
-TODO
+If we do not find a valid entry in our supplemental page-table it could be
+very well be a valid stack access. The maximum offset we consider as a valid
+access is due to the PUSHA instruction, which can try to access an address 32
+bytes below the current stack pointer. If this is the case we try to grow the
+stack by one page.
+
 
                    MEMORY MAPPED FILES
                    ===================