X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=TODO;h=40c15e7d9c10da4a40efd23a0cedbc6b7934bbcb;hb=cdc1ff02d0f3a0d57cd41e9794d26b62bfc65015;hp=3d6ec6930c325caecf3ef4d9221bf5f442607a27;hpb=07a2492de06739be5e43f92cf2088c0d39e46032;p=pintos-anon diff --git a/TODO b/TODO index 3d6ec69..40c15e7 100644 --- a/TODO +++ b/TODO @@ -1,5 +1,140 @@ -*- text -*- +* Bochs is not fully reproducible. + +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. + +- In Project 2, we're missing a test that would fail if they assumed +that contiguous user-virtual addresses are laid out contiguously +in memory. The loading code should ensure that non-contiguous +physical pages are allocated for the data segment (at least.) + +- 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: priority donation tests +To: "Ben Pfaff" +Date: Fri, 3 Mar 2006 11:02:08 -0500 + +Ben, + +it seems the priority donation tests are somewhat incomplete and allow +incorrect implementations to pass with a perfect score. + +We are seeing the following wrong implementations pass all tests: + +- Implementations that assume locks are released in the opposite order +in which they're acquired. The students implement this by +popping/pushing on the donation list. + +- Implementations that assume that the priority of a thread waiting on +a semaphore or condition variable cannot change between when the +thread was blocked and when it is unblocked. The students implement +this by doing an insert into an ordered list on block, rather than +picking the maximum thread on unblock. + +Neither of these two cases is detected; do you currently check for +these mistakes manually? + +I wrote a test that checks for the first case; it is here: +http://people.cs.vt.edu/~gback/pintos/priority-donate-multiple-2.patch + +[...] + +I also wrote a test case for the second scenario: +http://people.cs.vt.edu/~gback/pintos/priority-donate-sema.c +http://people.cs.vt.edu/~gback/pintos/priority-donate-sema.ck + +I put the other tests up here: +http://people.cs.vt.edu/~gback/pintos/priority-donate-multiple2.c +http://people.cs.vt.edu/~gback/pintos/priority-donate-multiple2.ck + +From: "Godmar Back" +Subject: multiple threads waking up at same clock tick +To: "Ben Pfaff" +Date: Wed, 1 Mar 2006 08:14:47 -0500 + +Greg Benson points out another potential TODO item for P1. + +---- +One thing I recall: + +The alarm tests do not test to see if multiple threads are woken up if +their timers have expired. That is, students can write a solution +that just wakes up the first thread on the sleep queue rather than +check for additional threads. Of course, the next thread will be +woken up on the next tick. Also, this might be hard to test. + +--- +Way to test this: (from Godmar Back) + +Thread A with high priority spins until 'ticks' changes, then calls to +timer_sleep(X), Thread B with lower priority is then resumed, calls +set_priority to make its priority equal to that of thread A, then +calls timer_sleep(X), all of that before the next clock interrupt +arrives. + +On wakeup, each thread records wake-up time and calls yield +immediately, forcing the scheduler to switch to the other +equal-priority thread. Both wake-up times must be the same (and match +the planned wake-up time.) + +PS: +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: "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 @@ -86,11 +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. - - - * process_death test needs improvement * Internal tests. @@ -137,3 +267,66 @@ via Godmar Back: . 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.