-*- text -*-
-* Test pintos with GSX.
+Godmar says:
-* Need targets for checking single tests or single subdirs
+- 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.
- - `make check' should say how to get more information
+- 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.
- - `make recheck', `make clean-check'
+- 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.
-* Need to put time limits on tests.
+From: "Godmar Back" <godmar@gmail.com>
+Subject: set_priority & donation - a TODO item
+To: "Ben Pfaff" <blp@cs.stanford.edu>
+Date: Mon, 20 Feb 2006 22:20:26 -0500
-* Add a way for students to prints messages ignored by the autograder.
+Ben,
- - Ignore text between /* and */.
+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.
- - Allow for a comment on `exit' lines?
+ - Godmar
-* Improve automatic interpretation of exception messages.
+From: Godmar Back <godmar@gmail.com>
+Subject: on caching in project 4
+To: Ben Pfaff <blp@cs.stanford.edu>
+Date: Mon, 9 Jan 2006 20:58:01 -0500
-* debug_backtrace() in kernel should only dereference valid pointers.
+here's an idea for future semesters.
-* We need better and more example programs.
+I'm in the middle of project 4, I've started by implementing a buffer
+cache and plugging it into the existing filesystem. Along the way I
+was wondering how we could test the cache.
- - Need an mmap example program as a replacement for the crappy mmap FAQ
- question.
+Maybe one could adopt a similar testing strategy as in project 1 for
+the MLQFS scheduler: add a function that reads "get_cache_accesses()"
+and a function "get_cache_hits()". Then create a version of pintos
+that creates access traces for a to-be-determined workload. Run an
+off-line analysis that would determine how many hits a perfect cache
+would have (MAX), and how much say an LRU strategy would give (MIN).
+Then add a fudge factor to account for different index strategies and
+test that the reported number of cache hits/accesses is within (MIN,
+MAX) +/- fudge factor.
- - How about `diff' and `cmp' programs?
+(As an aside - I am curious why you chose to use a clock-style
+algorithm rather than the more straightforward LRU for your buffer
+cache implementation in your sample solution. Is there a reason for
+that? I was curious to see if it made a difference, so I implemented
+LRU for your cache implementation and ran the test workload of project
+4 and printed cache hits/accesses.
+I found that for that workload, the clock-based algorithm performs
+almost identical to LRU (within about 1%, but I ran nondeterministally
+with QEMU). I then reduced the cache size to 32 blocks and found again
+the same performance, which raises the suspicion that the test
+workload might not force any cache replacement, so the eviction
+strategy doesn't matter.)
-* Threads:
+* Get rid of rox--causes more trouble than it's worth
- - mlfqs tests suck. They aren't even correct, e.g. the amarv
- submission from win0405 is graded incorrectly.
+* Reconsider command line arg style--confuses everyone.
-* Userprog project:
+* Finish writing tour.
+
+via Godmar Back:
+
+* Get rid of mmap syscall, add sbrk.
+
+* page-linear, page-shuffle VM tests do not use enough memory to force
+ eviction. Should increase memory consumption.
+
+* Add FS persistence test(s).
+
+* process_death test needs improvement
+
+* Internal tests.
- - Don't emphasize that stuff needs to be copied from user space to
- kernel space. Instead, emphasize validation and suggest that
- copying is a common solution and that it will be necessary in
- project 3 and in real OSes. Also revise the grading criteria to
- match.
+* 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
Alternately we could just remove the synchronization on pid
selection and check that students fix it.
-* VM project:
-
- - Discuss the perils of mixing dirty bits between kernel and user virtual
- memory.
-
- - Sample solution.
-
- - Update grading/vm to reflect new mmap, munmap forms.
-
* Filesys project:
- - Increase maximum disk size from 8 MB to something that actually
- requires doubly indirect nodes. There is a negative pressure here
- from the bitmap object--perhaps we need a specialized bitmap that
- doesn't have to be all in-memory at once.
-
- Alternatively, shrink the inode size.
-
- - Add option to disable buffer cache.
-
- - Sample solution.
-
- Need a better way to measure performance improvement of buffer
cache. Some students reported that their system was slower with
cache--likely, Bochs doesn't simulate a disk with a realistic
speed.
- - Clarify effect of remove(cwd).
-
* Documentation:
- - Finish writing tour.
-
- Add "Digging Deeper" sections that describe the nitty-gritty x86
details for the benefit of those interested.
- Add explanations of what "real" OSes do to give students some
perspective.
- - GNU make 3.80 or later is required.
-
* Assignments:
- Add extra credit:
. everything needed for getcwd()
-* Tests:
+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:
- - Release some of them.
+- Needs to be able to scan PCI bus for UHCI controller. (I
+ implemented this partially.)
- - The threads, userprog, vm test source files could use
- factorization and cleanup along the lines of fslib in the filesys
- tests.
+- 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.)
- - The p1-4.c testcase needs significant tuning. Currently it takes
- too long (especially when SHOW_PROGRESS is turned on) and doesn't
- show significant improvement.
+- 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.
-* Code:
+- 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.
- - Need an optimization barrier and an explanation of it in the
- documentation.
+- 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.
- - Need to check the wait system call more thoroughly.
+- Might want to add a feature whereby kernel arguments can be given
+ interactively, rather than passed on-disk. Needs some though.
projects / pintos-anon / blobdiff