pintos-os.org Git - pintos-anon/blob - TODO

   1 -*- text -*-
   2
   3 Godmar says:
   4
   5 - In Project 2, we're missing tests that pass arguments to system calls
   6 that span multiple pages, where some are mapped and some are not.
   7 An implementation that only checks the first page, rather than all pages
   8 that can be touched during a call to read()/write() passes all tests.
   9
  10 - Need some tests that test that illegal accesses lead to process
  11 termination. I have written some, will add them. In P2, obviously,
  12 this would require that the students break this functionality since
  13 the page directory is initialized for them, still it would be good
  14 to have.
  15
  16 - There does not appear to be a test that checks that they close all
  17 fd's on exit.  Idea: add statistics & self-diagnostics code to palloc.c
  18 and malloc.c.  Self-diagnostics code could be used for debugging.
  19 The statistics code would report how much kernel memory is free.
  20 Add a system call "get_kernel_memory_information".  User programs
  21 could engage in a variety of activities and notice leaks by checking
  22 the kernel memory statistics.
  23
  24 From: Godmar Back <godmar@gmail.com>
  25 Subject: on caching in project 4
  26 To: Ben Pfaff <blp@cs.stanford.edu>
  27 Date: Mon, 9 Jan 2006 20:58:01 -0500
  28
  29 here's an idea for future semesters.
  30
  31 I'm in the middle of project 4, I've started by implementing a buffer
  32 cache and plugging it into the existing filesystem.  Along the way I
  33 was wondering how we could test the cache.
  34
  35 Maybe one could adopt a similar testing strategy as in project 1 for
  36 the MLQFS scheduler: add a function that reads "get_cache_accesses()"
  37 and a function "get_cache_hits()".  Then create a version of pintos
  38 that creates access traces for a to-be-determined workload.  Run an
  39 off-line analysis that would determine how many hits a perfect cache
  40 would have (MAX), and how much say an LRU strategy would give (MIN).
  41 Then add a fudge factor to account for different index strategies and
  42 test that the reported number of cache hits/accesses is within (MIN,
  43 MAX) +/- fudge factor.
  44
  45 (As an aside - I am curious why you chose to use a clock-style
  46 algorithm rather than the more straightforward LRU for your buffer
  47 cache implementation in your sample solution. Is there a reason for
  48 that?  I was curious to see if it made a difference, so I implemented
  49 LRU for your cache implementation and ran the test workload of project
  50 4 and printed cache hits/accesses.
  51 I found that for that workload, the clock-based algorithm performs
  52 almost identical to LRU (within about 1%, but I ran nondeterministally
  53 with QEMU). I then reduced the cache size to 32 blocks and found again
  54 the same performance, which raises the suspicion that the test
  55 workload might not force any cache replacement, so the eviction
  56 strategy doesn't matter.)
  57
  58 * Get rid of rox--causes more trouble than it's worth
  59
  60 * Reconsider command line arg style--confuses everyone.
  61
  62 * Finish writing tour.
  63
  64 via Godmar Back:
  65
  66 * Get rid of mmap syscall, add sbrk.
  67
  68 * page-linear, page-shuffle VM tests do not use enough memory to force
  69   eviction.  Should increase memory consumption.
  70
  71 * Add FS persistence test(s).
  72
  73 * process_death test needs improvement
  74
  75 * Internal tests.
  76
  77 * Improve automatic interpretation of exception messages.
  78
  79 * Filesys project:
  80
  81   - Need a better way to measure performance improvement of buffer
  82     cache.  Some students reported that their system was slower with
  83     cache--likely, Bochs doesn't simulate a disk with a realistic
  84     speed.
  85
  86 * Documentation:
  87
  88   - Add "Digging Deeper" sections that describe the nitty-gritty x86
  89     details for the benefit of those interested.
  90
  91   - Add explanations of what "real" OSes do to give students some
  92     perspective.
  93
  94 * Assignments:
  95
  96   - Add extra credit:
  97
  98     . Specifics on how to implement sbrk, malloc.
  99
 100     . Other good ideas.
 101
 102     . opendir/readdir/closedir
 103
 104     . everything needed for getcwd()
 105
 106 To add partition support:
 107
 108 - Find four partition types that are more or less unused and choose to
 109   use them for Pintos.  (This is implemented.)
 110
 111 - Bootloader reads partition tables of all BIOS devices to find the
 112   first that has the "Pintos kernel" partition type.  (This is
 113   implemented.)  Ideally the bootloader would make sure there is
 114   exactly one such partition, but I didn't implement that yet.
 115
 116 - Bootloader reads kernel into memory at 1 MB using BIOS calls.  (This
 117   is implemented.)
 118
 119 - Kernel arguments have to go into a separate sector because the
 120   bootloader is otherwise too big to fit now?  (I don't recall if I
 121   did anything about this.)
 122
 123 - Kernel at boot also scans partition tables of all the disks it can
 124   find to find the ones with the four Pintos partition types (perhaps
 125   not all exist).  After that, it makes them available to the rest of
 126   the kernel (and doesn't allow access to other devices, for safety).
 127
 128 - "pintos" and "pintos-mkdisk" need to write a partition table to the
 129   disks that they create.  "pintos-mkdisk" will need to take a new
 130   parameter specifying the type.  (I might have partially implemented
 131   this, don't remember.)
 132
 133 - "pintos" should insist on finding a partition header on disks handed
 134   to it, for safety.
 135
 136 - Need some way for "pintos" to assemble multiple disks or partitions
 137   into a single image that can be copied directly to a USB block
 138   device.  (I don't know whether I came up with a good solution yet or
 139   not, or whether I implemented any of it.)
 140
 141 To add USB support:
 142
 143 - Needs to be able to scan PCI bus for UHCI controller.  (I
 144   implemented this partially.)
 145
 146 - May want to be able to initialize USB controllers over CardBus
 147   bridges.  I don't know whether this requires additional work or if
 148   it's useful enough to warrant extra work.  (It's of special interest
 149   for me because I have a laptop that only has USB via CardBus.)
 150
 151 - There are many protocol layers involved: SCSI over USB-Mass Storage
 152   over USB over UHCI over PCI.  (I may be forgetting one.)  I don't
 153   know yet whether it's best to separate the layers or to merge (some
 154   of) them.  I think that a simple and clean organization should be a
 155   priority.
 156
 157 - VMware can likely be used for testing because it can expose host USB
 158   devices as guest USB devices.  This is safer and more convenient
 159   than using real hardware for testing.
 160
 161 - Should test with a variety of USB keychain devices because there
 162   seems to be wide variation among them, especially in the SCSI
 163   protocols they support.  Should try to use a "lowest-common
 164   denominator" SCSI protocol if any such thing really exists.
 165
 166 - Might want to add a feature whereby kernel arguments can be given
 167   interactively, rather than passed on-disk.  Needs some though.