X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=TODO;h=8651fb419f1c97bbd423c692ca1b7c19674da016;hb=eed4f8684a66bc3068c5c8aeae56a5aa9cc3e5e1;hp=017db82200fa63932869c6b92a4ddfc323714196;hpb=b0989f883c16aeee2cb9278340601f15bcc15dd4;p=pintos-anon diff --git a/TODO b/TODO index 017db82..8651fb4 100644 --- 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" Subject: priority donation tests To: "Ben Pfaff" @@ -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" -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" -Subject: thread_yield in irq handler -To: "Ben Pfaff" -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" 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.