X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=TODO;h=7d6ba406ed2365122dc213cb8b30da257f582db2;hb=31711e65718e8334dbb672eca64b6b4b906d1a03;hp=6fb051b0e85314714f43bb4c32d0841dc446059b;hpb=7d3be19477505cbf611db505f371037c9c51b574;p=pintos-anon

diff --git a/TODO b/TODO
index 6fb051b..7d6ba40 100644
--- a/TODO
+++ b/TODO
@@ -1,42 +1,38 @@
 -*- text -*-
 
-* Test pintos with GSX.
+* Get rid of rox--causes more trouble than it's worth
 
-* Need targets for checking single tests or single subdirs
+* Reconsider command line arg style--confuses everyone.
 
-  - `make check' should say how to get more information
+* pintos script doesn't (always?) delete temp disks
 
-  - `make recheck', `make clean-check'
+* Finish writing tour.
 
-* Need to put time limits on tests.
+via Godmar Back:
 
-* Add a way for students to prints messages ignored by the autograder.
+* Project 3 solution needs FS lock.
 
-  - Ignore text between /* and */.
+* Get rid of mmap syscall, add sbrk.
 
-  - Allow for a comment on `exit' lines?
+* hash_destroy() should take function arg.
 
-* Improve automatic interpretation of exception messages.
+* Make backtrace program accept multiple object file arguments,
+  e.g. add -u option to allow backtracing user program also.
 
-* We need better and more example programs.
+* VM projects do not use enough memory to force eviction.
+  Should reduce user limit or increase memory consumption.
 
-  - Need an mmap example program as a replacement for the crappy mmap FAQ
-    question.
 
-  - How about `diff' and `cmp' programs?
 
-* Threads:
 
-  - mlfqs tests suck.  They aren't even correct, e.g. the amarv
-    submission from win0405 is graded incorrectly.
 
-* Userprog project:
+* process_death test needs improvement
+
+* Internal tests.
+
+* Improve automatic interpretation of exception messages.
 
-  - Don't emphasize that stuff needs to be copied from user space to
-    kernel space.  Instead, emphasize validation and suggest that
-    copying is a common solution and that it will be necessary in
-    project 3 and in real OSes.  Also revise the grading criteria to
-    match.
+* 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
@@ -48,41 +44,21 @@
     Alternately we could just remove the synchronization on pid
     selection and check that students fix it.
 
-* VM project:
-
-  - Discuss the perils of mixing dirty bits between kernel and user virtual
-    memory.
-
 * Filesys project:
 
-  - Increase maximum disk size from 8 MB to something that actually
-    requires doubly indirect nodes.  There is a negative pressure here
-    from the bitmap object--perhaps we need a specialized bitmap that
-    doesn't have to be all in-memory at once.
-
-    Alternatively, shrink the inode size.
-
-  - Add option to disable buffer cache.
-
   - Need a better way to measure performance improvement of buffer
     cache.  Some students reported that their system was slower with
     cache--likely, Bochs doesn't simulate a disk with a realistic
     speed.
 
-  - Clarify effect of remove(cwd).
-
 * Documentation:
 
-  - Finish writing tour.
-
   - Add "Digging Deeper" sections that describe the nitty-gritty x86
     details for the benefit of those interested.
 
   - Add explanations of what "real" OSes do to give students some
     perspective.
 
-  - GNU make 3.80 or later is required.
-
 * Assignments:
 
   - Add extra credit:
@@ -96,20 +72,3 @@
     . opendir/readdir/closedir
 
     . everything needed for getcwd()
-
-* Tests:
-
-  - The threads, userprog, vm test source files could use
-    factorization and cleanup along the lines of fslib in the filesys
-    tests.
-
-  - The p1-4.c testcase needs significant tuning.  Currently it takes
-    too long (especially when SHOW_PROGRESS is turned on) and doesn't
-    show significant improvement.
-
-* Code:
-
-  - Need an optimization barrier and an explanation of it in the
-    documentation.
-
-  - Need to check the wait system call more thoroughly.