-*- text -*-
-* Bochs is not fully reproducible.
-
Godmar says:
- In Project 2, we're missing tests that pass arguments to system calls
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.
-- In Project 2, we're missing a test that would fail if they assumed
-that contiguous user-virtual addresses are laid out contiguously
-in memory. The loading code should ensure that non-contiguous
-physical pages are allocated for the data segment (at least.)
-
- 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
could engage in a variety of activities and notice leaks by checking
the kernel memory statistics.
----
-
-From: "Godmar Back" <godmar@gmail.com>
-Subject: priority donation tests
-To: "Ben Pfaff" <blp@cs.stanford.edu>
-Date: Fri, 3 Mar 2006 11:02:08 -0500
-
-Ben,
-
-it seems the priority donation tests are somewhat incomplete and allow
-incorrect implementations to pass with a perfect score.
-
-We are seeing the following wrong implementations pass all tests:
-
-- Implementations that assume locks are released in the opposite order
-in which they're acquired. The students implement this by
-popping/pushing on the donation list.
-
-- Implementations that assume that the priority of a thread waiting on
-a semaphore or condition variable cannot change between when the
-thread was blocked and when it is unblocked. The students implement
-this by doing an insert into an ordered list on block, rather than
-picking the maximum thread on unblock.
-
-Neither of these two cases is detected; do you currently check for
-these mistakes manually?
-
-I wrote a test that checks for the first case; it is here:
-http://people.cs.vt.edu/~gback/pintos/priority-donate-multiple-2.patch
-
-[...]
-
-I also wrote a test case for the second scenario:
-http://people.cs.vt.edu/~gback/pintos/priority-donate-sema.c
-http://people.cs.vt.edu/~gback/pintos/priority-donate-sema.ck
-
-I put the other tests up here:
-http://people.cs.vt.edu/~gback/pintos/priority-donate-multiple2.c
-http://people.cs.vt.edu/~gback/pintos/priority-donate-multiple2.ck
-
-From: "Godmar Back" <godmar@gmail.com>
-Subject: multiple threads waking up at same clock tick
-To: "Ben Pfaff" <blp@cs.stanford.edu>
-Date: Wed, 1 Mar 2006 08:14:47 -0500
-
-Greg Benson points out another potential TODO item for P1.
-
-----
-One thing I recall:
-
-The alarm tests do not test to see if multiple threads are woken up if
-their timers have expired. That is, students can write a solution
-that just wakes up the first thread on the sleep queue rather than
-check for additional threads. Of course, the next thread will be
-woken up on the next tick. Also, this might be hard to test.
-
----
-Way to test this: (from Godmar Back)
-
-Thread A with high priority spins until 'ticks' changes, then calls to
-timer_sleep(X), Thread B with lower priority is then resumed, calls
-set_priority to make its priority equal to that of thread A, then
-calls timer_sleep(X), all of that before the next clock interrupt
-arrives.
-
-On wakeup, each thread records wake-up time and calls yield
-immediately, forcing the scheduler to switch to the other
-equal-priority thread. Both wake-up times must be the same (and match
-the planned wake-up time.)
-
-PS:
-I actually tested it and it's hard to pass with the current ips setting.
-The bounds on how quickly a thread would need to be able to return after
-sleep appear too tight. Need another idea.
-
-From: "Godmar Back" <godmar@gmail.com>
-Subject: thread_yield in irq handler
-To: "Ben Pfaff" <blp@cs.stanford.edu>
-Date: Wed, 22 Feb 2006 22:18:50 -0500
-
-Ben,
-
-you write in your Tour of Pintos:
-
-"Second, an interrupt handler must not call any function that can
-sleep, which rules out thread_yield(), lock_acquire(), and many
-others. This is because external interrupts use space on the stack of
-the kernel thread that was running at the time the interrupt occurred.
-If the interrupt handler tried to sleep and that thread resumed, then
-the two uses of the single stack would interfere, which cannot be
-allowed."
-
-Is the last sentence really true?
-
-I thought the reason that you couldn't sleep is that you would put
-effectively a random thread/process to sleep, but I don't think it
-would cause problems with the kernel stack. After all, it doesn't
-cause this problem if you call thread_yield at the end of
-intr_handler(), so why would it cause this problem earlier.
-
-As for thread_yield(), my understanding is that the reason it's called
-at the end is to ensure it's done after the interrupt is acknowledged,
-which you can't do until the end because Pintos doesn't handle nested
-interrupts.
-
- - Godmar
-
-From: "Godmar Back" <godmar@gmail.com>
-
-For reasons I don't currently understand, some of our students seem
-hesitant to include each thread in a second "all-threads" list and are
-looking for ways to implement the advanced scheduler without one.
-
-Currently, I believe, all tests for the mlfqs are such that all
-threads are either ready or sleeping in timer_sleep(). This allows for
-an incorrect implementation in which recent-cpu and priorities are
-updated only for those threads that are on the alarm list or the ready
-list.
-
-The todo item would be a test where a thread is blocked on a
-semaphore, lock or condition variable and have its recent_cpu decay to
-zero, and check that it's scheduled right after the unlock/up/signal.
-
From: "Godmar Back" <godmar@gmail.com>
Subject: set_priority & donation - a TODO item
To: "Ben Pfaff" <blp@cs.stanford.edu>
- Godmar
-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
-
From: Godmar Back <godmar@gmail.com>
Subject: on caching in project 4
To: Ben Pfaff <blp@cs.stanford.edu>
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.
-* Introduce a "yield" system call to speed up the syn-* tests.
-
via Godmar Back:
-* Project 3 solution needs FS lock.
-
* 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).
-* lock_acquire(), lock_release() don't need additional intr_dis/enable
- calls, because the semaphore protects lock->holder.
- [ Think this over: is this really true when priority donation is
- implemented? intr_dis/enable prevents the race with thread_set_priority.
- Leaving it there could help the students getting the correct synchronization
- right.
- ]
-
-
-
* process_death test needs improvement
* Internal tests.
. opendir/readdir/closedir
. 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.
projects / pintos-anon / blobdiff