X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=TODO;h=38836157fc052fe3a07b91d5d03bea94c64ac104;hb=0254ba2271aad44ff5e048be807b7cdaf15b597e;hp=108c77781edbc23b732af89b6b5d1e71fe5e616d;hpb=09bbcd059d4ce05bf6b8da829795409e2da9a899;p=pintos-anon diff --git a/TODO b/TODO index 108c777..3883615 100644 --- a/TODO +++ b/TODO @@ -1,157 +1,25 @@ -*- text -*- -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 -hesitant to include each thread in a second "all-threads" list and are -looking for ways to implement the advanced scheduler without one. - -Currently, I believe, all tests for the mlfqs are such that all -threads are either ready or sleeping in timer_sleep(). This allows for -an incorrect implementation in which recent-cpu and priorities are -updated only for those threads that are on the alarm list or the ready -list. - -The todo item would be a test where a thread is blocked on a -semaphore, lock or condition variable and have its recent_cpu decay to -zero, and check that it's scheduled right after the unlock/up/signal. - -From: "Godmar Back" -Subject: set_priority & donation - a TODO item -To: "Ben Pfaff" -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 -Subject: project 4 question/comment regarding caching inode data -To: Ben Pfaff -Date: Sat, 14 Jan 2006 15:59:33 -0500 - -Ben, - -in section 6.3.3 in the P4 FAQ, you write: - -"You can store a pointer to inode data in struct inode, if you want," - -Should you point out that if they indeed do that, they likely wouldn't -be able to support more than 64 open inodes systemwide at any given -point in time. - -(This seems like a rather strong limitation; do your current tests -open more than 64 files? -It would also point to an obvious way to make the projects harder by -specifically disallowing that inode data be locked in memory during -the entire time an inode is kept open.) - - - Godmar +Godmar says: + +- In Project 2, we're missing tests that pass arguments to system calls +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. + +- 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 +the page directory is initialized for them, still it would be good +to have. + +- There does not appear to be a test that checks that they close all +fd's on exit. Idea: add statistics & self-diagnostics code to palloc.c +and malloc.c. Self-diagnostics code could be used for debugging. +The statistics code would report how much kernel memory is free. +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 Subject: on caching in project 4 @@ -187,58 +55,25 @@ 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 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. * Finish writing tour. -* Introduce a "yield" system call to speed up the syn-* tests. - via Godmar Back: -* Project 3 solution needs FS lock. - * Get rid of mmap syscall, add sbrk. -* Make backtrace program accept multiple object file arguments, - e.g. add -u option to allow backtracing user program also. - * page-linear, page-shuffle VM tests do not use enough memory to force eviction. Should increase memory consumption. * Add FS persistence test(s). -* lock_acquire(), lock_release() don't need additional intr_dis/enable - calls, because the semaphore protects lock->holder. - - - * process_death test needs improvement * 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 @@ -258,12 +93,71 @@ 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: + +- Find four partition types that are more or less unused and choose to + use them for Pintos. (This is implemented.) + +- Bootloader reads partition tables of all BIOS devices to find the + first that has the "Pintos kernel" partition type. (This is + implemented.) Ideally the bootloader would make sure there is + exactly one such partition, but I didn't implement that yet. + +- Bootloader reads kernel into memory at 1 MB using BIOS calls. (This + is implemented.) + +- Kernel arguments have to go into a separate sector because the + bootloader is otherwise too big to fit now? (I don't recall if I + did anything about this.) + +- Kernel at boot also scans partition tables of all the disks it can + find to find the ones with the four Pintos partition types (perhaps + not all exist). After that, it makes them available to the rest of + the kernel (and doesn't allow access to other devices, for safety). + +- "pintos" and "pintos-mkdisk" need to write a partition table to the + disks that they create. "pintos-mkdisk" will need to take a new + parameter specifying the type. (I might have partially implemented + this, don't remember.) + +- "pintos" should insist on finding a partition header on disks handed + to it, for safety. + +- Need some way for "pintos" to assemble multiple disks or partitions + into a single image that can be copied directly to a USB block + device. (I don't know whether I came up with a good solution yet or + not, or whether I implemented any of it.) + +To add USB support: + +- Needs to be able to scan PCI bus for UHCI controller. (I + implemented this partially.) + +- May want to be able to initialize USB controllers over CardBus + bridges. I don't know whether this requires additional work or if + it's useful enough to warrant extra work. (It's of special interest + for me because I have a laptop that only has USB via CardBus.) + +- There are many protocol layers involved: SCSI over USB-Mass Storage + over USB over UHCI over PCI. (I may be forgetting one.) I don't + know yet whether it's best to separate the layers or to merge (some + of) them. I think that a simple and clean organization should be a + priority. + +- VMware can likely be used for testing because it can expose host USB + devices as guest USB devices. This is safer and more convenient + than using real hardware for testing. + +- Should test with a variety of USB keychain devices because there + seems to be wide variation among them, especially in the SCSI + protocols they support. Should try to use a "lowest-common + denominator" SCSI protocol if any such thing really exists. + +- Might want to add a feature whereby kernel arguments can be given + interactively, rather than passed on-disk. Needs some though.