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

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