Wordsmithing.

[pintos-anon] / TODO

diff --git a/TODO b/TODO
index bb96b8825e807c5694453c3b222149a24ede4ca6..38836157fc052fe3a07b91d5d03bea94c64ac104 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,27 +1,25 @@
 -*- text -*-
 
 -*- text -*-
 

-From: Godmar Back <godmar@gmail.com>
-Subject: project 4 question/comment regarding caching inode data
-To: Ben Pfaff <blp@cs.stanford.edu>
-Date: Sat, 14 Jan 2006 15:59:33 -0500
-
-Ben,
-
-in section 6.3.3 in the P4 FAQ, you write:
-
-"You can store a pointer to inode data in struct inode, if you want,"
-
-Should you point out that if they indeed do that, they likely wouldn't
-be able to support more than 64 open inodes systemwide at any given
-point in time.
-
-(This seems like a rather strong limitation; do your current tests
-open more than 64 files?
-It would also point to an obvious way to make the projects harder by
-specifically disallowing that inode data be locked in memory during
-the entire time an inode is kept open.)
-
- - Godmar
+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.
+
+- 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 <godmar@gmail.com>
 Subject: on caching in project 4
 
 From: Godmar Back <godmar@gmail.com>
 Subject: on caching in project 4


@@ -57,57 +55,25 @@ the same performance, which raises the suspicion that the test
 workload might not force any cache replacement, so the eviction
 strategy doesn't matter.)
 
 workload might not force any cache replacement, so the eviction
 strategy doesn't matter.)
 

-Godmar Back <godmar@gmail.com> writes:
-
-> in your sample solution to P4, dir_reopen does not take any locks when
-> changing a directory's open_cnt. This looks like a race condition to
-> me, considering that dir_reopen is called from execute_process without
-> any filesystem locks held.
-

 * Get rid of rox--causes more trouble than it's worth
 
 * Reconsider command line arg style--confuses everyone.
 
 * Finish writing tour.
 
 * Get rid of rox--causes more trouble than it's worth
 
 * Reconsider command line arg style--confuses everyone.
 
 * Finish writing tour.
 

-* Introduce a "yield" system call to speed up the syn-* tests.
-

 via Godmar Back:
 
 via Godmar Back:
 

-* Project 3 solution needs FS lock.
-

 * Get rid of mmap syscall, add sbrk.
 
 * Get rid of mmap syscall, add sbrk.
 

-* Make backtrace program accept multiple object file arguments,
-  e.g. add -u option to allow backtracing user program also.
-

 * page-linear, page-shuffle VM tests do not use enough memory to force
   eviction.  Should increase memory consumption.
 
 * Add FS persistence test(s).
 
 * 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.
 
 * process_death test needs improvement
 
 * Internal tests.
 

-* 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
-    students, require them to do it.
-
-  - Don't provide per-process pagedir implementation but only
-    single-process implementation and require students to implement
-    the separation?  This project was rated as the easiest after all.
-    Alternately we could just remove the synchronization on pid
-    selection and check that students fix it.
-

 * Filesys project:
 
   - Need a better way to measure performance improvement of buffer
 * Filesys project:
 
   - Need a better way to measure performance improvement of buffer


@@ -127,12 +93,71 @@ via Godmar Back:
 
   - Add extra credit:
 
 
   - Add extra credit:
 

-    . Low-level x86 stuff, like paged page tables.
-

     . Specifics on how to implement sbrk, malloc.
 
     . Other good ideas.
 
     . Specifics on how to implement sbrk, malloc.
 
     . Other good ideas.
 

-    . opendir/readdir/closedir
-

     . everything needed for getcwd()
     . 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.