Proofreading.
[pintos-anon] / TODO
diff --git a/TODO b/TODO
index 017db82200fa63932869c6b92a4ddfc323714196..8651fb419f1c97bbd423c692ca1b7c19674da016 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,5 +1,7 @@
 -*- text -*-
 
+* Bochs is not fully reproducible.
+
 Godmar says:
 
 - In Project 2, we're missing tests that pass arguments to system calls
@@ -28,7 +30,6 @@ the kernel memory statistics.
 
 ---
 
-
 From: "Godmar Back" <godmar@gmail.com>
 Subject: priority donation tests
 To: "Ben Pfaff" <blp@cs.stanford.edu>
@@ -102,105 +103,6 @@ I actually tested it and it's hard to pass with the current ips setting.
 The bounds on how quickly a thread would need to be able to return after
 sleep appear too tight.  Need another idea.
 
----
-From: "Waqar Mohsin" <wmohsin@gmail.com>
-Subject: 3 questions about switch_threads() in switch.S
-To: blp@cs.stanford.edu, joshwise@stanford.edu
-Date: Fri, 3 Mar 2006 17:09:21 -0800
-
-QUESTION 1
-In the section
-  # Save current stack pointer to old thread's stack, if any.
-  movl SWITCH_CUR(%esp), %eax
-  test %eax, %eax
-  jz 1f
-  movl %esp, (%eax,%edx,1)
-1:
-
-  # Restore stack pointer from new thread's stack.
-  movl SWITCH_NEXT(%esp), %ecx
-  movl (%ecx,%edx,1), %esp
-
-why are we saving the current stack pointer only if the "cur" thread pointer
-is non-NULL ? Isn't it gauranteed to be non-NULL because switch_threads() is
-only called form schedule(), where we have
-
-  struct thread *cur = running_thread ();
-
-which should always be non-NULL (given the way kernel pool is laid out).
-
-QUESTION 2
-
-  # This stack frame must match the one set up by thread_create().
-  pushl %ebx
-  pushl %ebp
-  pushl %esi
-  pushl %edi
-
-I find the comment confusing. thread_create() is a special case: the set of
-registers popped from switch_threads stack frame for a newly created thread
-are all zero, so their order shouldn't dictate the order above.
-
-I think all that matters is that the order of pops at the end of
-switch_threads() is the opposite of the pushes at the beginning (as shown
-above).
-
-QUESTION 3
-
-Is it true that struct switch_threads_frame does NOT strictly require
-
-    struct thread *cur;         /* 20: switch_threads()'s CUR argument. */
-    struct thread *next;        /* 24: switch_threads()'s NEXT argument. */
-at the end ?
-
-When a newly created thread's stack pointer is installed in switch_threads(),
-all we do is pop the saved registers and return to switch_entry() which pops
-off and discards the above two simulated (and not used) arguments to
-switch_threads().
-
-If we remove these two from struct switch_threads_frame and don't do a
-
-  # Discard switch_threads() arguments.
-  addl $8, %esp
-in switch_entry(), things should still work. Am I right ?
-
-Thanks
-Waqar
-
-From: "Godmar Back" <godmar@gmail.com>
-Subject: thread_yield in irq handler
-To: "Ben Pfaff" <blp@cs.stanford.edu>
-Date: Wed, 22 Feb 2006 22:18:50 -0500
-
-Ben,
-
-you write in your Tour of Pintos:
-
-"Second, an interrupt handler must not call any function that can
-sleep, which rules out thread_yield(), lock_acquire(), and many
-others. This is because external interrupts use space on the stack of
-the kernel thread that was running at the time the interrupt occurred.
-If the interrupt handler tried to sleep and that thread resumed, then
-the two uses of the single stack would interfere, which cannot be
-allowed."
-
-Is the last sentence really true?
-
-I thought the reason that you couldn't sleep is that you would put
-effectively a random thread/process to sleep, but I don't think it
-would cause problems with the kernel stack.  After all, it doesn't
-cause this problem if you call thread_yield at the end of
-intr_handler(), so why would it cause this problem earlier.
-
-As for thread_yield(), my understanding is that the reason it's called
-at the end is to ensure it's done after the interrupt is acknowledged,
-which you can't do until the end because Pintos doesn't handle nested
-interrupts.
-
- - Godmar
-
 From: "Godmar Back" <godmar@gmail.com>
 
 For reasons I don't currently understand, some of our students seem
@@ -319,16 +221,6 @@ via Godmar Back:
 
 * Add FS persistence test(s).
 
-* lock_acquire(), lock_release() don't need additional intr_dis/enable
-  calls, because the semaphore protects lock->holder.
-  [ Think this over: is this really true when priority donation is 
-    implemented?  intr_dis/enable prevents the race with thread_set_priority. 
-    Leaving it there could help the students getting the correct synchronization
-    right.
-  ]
-
-
-
 * process_death test needs improvement
 
 * Internal tests.