3 * Reconsider command line arg style--confuses everyone.
7 * Add serial input support. Also, modify tests to redirect input from
8 /dev/null, to avoid stray keystrokes getting sent into the VM.
10 * Make pintos script read the serial output and kill the subprocess if
11 it panics (after waiting a few seconds) or triple-faults. Might
12 want it to be optional, so that interactive users don't get killed.
16 - Get rid of rox--causes more trouble than it's worth
18 - Extra credit: specifics on how to implement sbrk, malloc.
20 - Godmar: We're missing tests that pass arguments to system calls
21 that span multiple pages, where some are mapped and some are not.
22 An implementation that only checks the first page, rather than all
23 pages that can be touched during a call to read()/write() passes
26 - Godmar: Need some tests that test that illegal accesses lead to
27 process termination. I have written some, will add them. In P2,
28 obviously, this would require that the students break this
29 functionality since the page directory is initialized for them,
30 still it would be good to have.
32 - Godmar: There does not appear to be a test that checks that they
33 close all fd's on exit. Idea: add statistics & self-diagnostics
34 code to palloc.c and malloc.c. Self-diagnostics code could be
35 used for debugging. The statistics code would report how much
36 kernel memory is free. Add a system call
37 "get_kernel_memory_information". User programs could engage in a
38 variety of activities and notice leaks by checking the kernel
41 - process_death test needs improvement
45 - Godmar: Get rid of mmap syscall, add sbrk.
47 - Godmar: page-linear, page-shuffle VM tests do not use enough
48 memory to force eviction. Should increase memory consumption.
52 - Need a better way to measure performance improvement of buffer
53 cache. Some students reported that their system was slower with
54 cache--likely, Bochs doesn't simulate a disk with a realistic
57 - Do we check that non-empty directories cannot be removed?
59 - Need lots more tests.
61 - Add FS persistence test(s).
63 - Godmar: I'm in the middle of project 4, I've started by
64 implementing a buffer cache and plugging it into the existing
65 filesystem. Along the way I was wondering how we could test the
68 Maybe one could adopt a similar testing strategy as in project 1
69 for the MLQFS scheduler: add a function that reads
70 "get_cache_accesses()" and a function "get_cache_hits()". Then
71 create a version of pintos that creates access traces for a
72 to-be-determined workload. Run an off-line analysis that would
73 determine how many hits a perfect cache would have (MAX), and how
74 much say an LRU strategy would give (MIN). Then add a fudge
75 factor to account for different index strategies and test that the
76 reported number of cache hits/accesses is within (MIN, MAX) +/-
79 (As an aside - I am curious why you chose to use a clock-style
80 algorithm rather than the more straightforward LRU for your buffer
81 cache implementation in your sample solution. Is there a reason
82 for that? I was curious to see if it made a difference, so I
83 implemented LRU for your cache implementation and ran the test
84 workload of project 4 and printed cache hits/accesses. I found
85 that for that workload, the clock-based algorithm performs almost
86 identical to LRU (within about 1%, but I ran nondeterministally
87 with QEMU). I then reduced the cache size to 32 blocks and found
88 again the same performance, which raises the suspicion that the
89 test workload might not force any cache replacement, so the
90 eviction strategy doesn't matter.)
94 - Add "Digging Deeper" sections that describe the nitty-gritty x86
95 details for the benefit of those interested.
97 - Add explanations of what "real" OSes do to give students some
100 * To add partition support:
102 - Find four partition types that are more or less unused and choose
103 to use them for Pintos. (This is implemented.)
105 - Bootloader reads partition tables of all BIOS devices to find the
106 first that has the "Pintos kernel" partition type. (This is
107 implemented.) Ideally the bootloader would make sure there is
108 exactly one such partition, but I didn't implement that yet.
110 - Bootloader reads kernel into memory at 1 MB using BIOS calls.
111 (This is implemented.)
113 - Kernel arguments have to go into a separate sector because the
114 bootloader is otherwise too big to fit now? (I don't recall if I
115 did anything about this.)
117 - Kernel at boot also scans partition tables of all the disks it can
118 find to find the ones with the four Pintos partition types
119 (perhaps not all exist). After that, it makes them available to
120 the rest of the kernel (and doesn't allow access to other devices,
123 - "pintos" and "pintos-mkdisk" need to write a partition table to
124 the disks that they create. "pintos-mkdisk" will need to take a
125 new parameter specifying the type. (I might have partially
126 implemented this, don't remember.)
128 - "pintos" should insist on finding a partition header on disks
129 handed to it, for safety.
131 - Need some way for "pintos" to assemble multiple disks or
132 partitions into a single image that can be copied directly to a
133 USB block device. (I don't know whether I came up with a good
134 solution yet or not, or whether I implemented any of it.)
136 * To add USB support:
138 - Needs to be able to scan PCI bus for UHCI controller. (I
139 implemented this partially.)
141 - May want to be able to initialize USB controllers over CardBus
142 bridges. I don't know whether this requires additional work or
143 if it's useful enough to warrant extra work. (It's of special
144 interest for me because I have a laptop that only has USB via
147 - There are many protocol layers involved: SCSI over USB-Mass
148 Storage over USB over UHCI over PCI. (I may be forgetting one.)
149 I don't know yet whether it's best to separate the layers or to
150 merge (some of) them. I think that a simple and clean
151 organization should be a priority.
153 - VMware can likely be used for testing because it can expose host
154 USB devices as guest USB devices. This is safer and more
155 convenient than using real hardware for testing.
157 - Should test with a variety of USB keychain devices because there
158 seems to be wide variation among them, especially in the SCSI
159 protocols they support. Should try to use a "lowest-common
160 denominator" SCSI protocol if any such thing really exists.
162 - Might want to add a feature whereby kernel arguments can be
163 given interactively, rather than passed on-disk. Needs some
projects / pintos-anon / blob