Remove fixed item.
authorBen Pfaff <blp@cs.stanford.edu>
Sun, 9 Apr 2006 19:55:03 +0000 (19:55 +0000)
committerBen Pfaff <blp@cs.stanford.edu>
Sun, 9 Apr 2006 19:55:03 +0000 (19:55 +0000)
TODO

diff --git a/TODO b/TODO
index 95bf2aeb4ff2994762d6440765fb3e85d03eb2f9..45b06ce068a72522a5acfd87cca5ec3f99304832 100644 (file)
--- a/TODO
+++ b/TODO
@@ -103,50 +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 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>