Comment.

[pintos-anon] / TODO

diff --git a/TODO b/TODO
index a4e3e31c080d3a2d5f0a004ec08f10e1d05bc540..38836157fc052fe3a07b91d5d03bea94c64ac104 100644 (file)
--- a/TODO
+++ b/TODO
@@ -7,11 +7,6 @@ that span multiple pages, where some are mapped and some are not.
 An implementation that only checks the first page, rather than all pages 
 that can be touched during a call to read()/write() passes all tests.
 
-- In Project 2, we're missing a test that would fail if they assumed
-that contiguous user-virtual addresses are laid out contiguously 
-in memory.  The loading code should ensure that non-contiguous 
-physical pages are allocated for the data segment (at least.)
-
 - Need some tests that test that illegal accesses lead to process
 termination. I have written some, will add them. In P2, obviously, 
 this would require that the students break this functionality since 
@@ -26,22 +21,6 @@ Add a system call "get_kernel_memory_information".  User programs
 could engage in a variety of activities and notice leaks by checking
 the kernel memory statistics.
 
-From: "Godmar Back" <godmar@gmail.com>
-Subject: set_priority & donation - a TODO item
-To: "Ben Pfaff" <blp@cs.stanford.edu>
-Date: Mon, 20 Feb 2006 22:20:26 -0500
-
-Ben,
-
-it seems that there are currently no tests that check the proper
-behavior of thread_set_priority() when called by a thread that is
-running under priority donation.  The proper behavior, I assume, is to
-temporarily drop the donation if the set priority is higher, and to
-reassume the donation should the thread subsequently set its own
-priority again to a level that's lower than a still active donation.
-
- - Godmar
-
 From: Godmar Back <godmar@gmail.com>
 Subject: on caching in project 4
 To: Ben Pfaff <blp@cs.stanford.edu>
@@ -76,13 +55,6 @@ the same performance, which raises the suspicion that the test
 workload might not force any cache replacement, so the eviction
 strategy doesn't matter.)
 
-Godmar Back <godmar@gmail.com> writes:
-
-> in your sample solution to P4, dir_reopen does not take any locks when
-> changing a directory's open_cnt. This looks like a race condition to
-> me, considering that dir_reopen is called from execute_process without
-> any filesystem locks held.
-
 * Get rid of rox--causes more trouble than it's worth
 
 * Reconsider command line arg style--confuses everyone.
@@ -102,20 +74,6 @@ via Godmar Back:
 
 * Internal tests.
 
-* Improve automatic interpretation of exception messages.
-
-* Userprog project:
-
-  - Mark read-only pages as actually read-only in the page table.  Or,
-    since this was consistently rated as the easiest project by the
-    students, require them to do it.
-
-  - Don't provide per-process pagedir implementation but only
-    single-process implementation and require students to implement
-    the separation?  This project was rated as the easiest after all.
-    Alternately we could just remove the synchronization on pid
-    selection and check that students fix it.
-
 * Filesys project:
 
   - Need a better way to measure performance improvement of buffer
@@ -135,14 +93,10 @@ via Godmar Back:
 
   - Add extra credit:
 
-    . Low-level x86 stuff, like paged page tables.
-
     . Specifics on how to implement sbrk, malloc.
 
     . Other good ideas.
 
-    . opendir/readdir/closedir
-
     . everything needed for getcwd()
 
 To add partition support: