R. Clayton (rclayton@monmouth.edu)
(no date)
I've issued a disk read for the index block, but when I look at the words in
memory where I stored that block, its all 0's. I assume its because I
haven't waited for the disk to finish the read.
If you've read the storage before the interrupt, yes. If you're reading after
the interrupt, it's most likely that you read a block that was previously
unwritten; in Unix fashion, such blocks are returned containing all zeros
(which will be something you'll need to keep in mind when designing your file
system). This all assumes the disk read ended successfully; if it didn't, then
the contents of storage are undefined.
I have to wait while the disk returns, so I have to run the idle process.
Yes.
When my interrupt handler for reboot finishes, control gets returned to
whoever called it
No. For interrupts, the "caller" is some device (the disk, the clock) or a
process causing a system-call interrupt. For devices, the os certainly doesn't
return to it when the interrupt's been handled. For processes it's more
complicated. With the exception of exit system calls (and fatally flawed
system calls) the os returns to the triggering process, but it doesn't have to
do it right away. P1 could raise a system-call interrupt, the os could handle
the interrupt, and then context switch to P2 (as it would if P1 raised a
blocking system call). When the os returns from the interrupt, P2 will be
running.
This project seems to be rough because we have to write a lot of pieces
before we can really test it.
That's true, which is why I gave you an increasingly more complicated set of
batch disks and a particular implementation order. It also means you should
shift your quality control from testing to larding your code with sanity checks
and assertions.
I think the assignment's rough because you can't write your own test cases.
You have to take what I give you, and you can't fiddle with them (do the
binary-chop thing to isolate the problem, for example). This is even harder
than writing real operating systems, because there you at least get a chance to
look at the program causing the problems (sometimes; if the problem's caused by
a proprietary program, you may not be able to swing a deal to get a look). On
the other hand, that's little consolation when the you've got a 1.5 million
line program that causes problems only after four hour of execution.
This archive was generated by hypermail 2.0b3 on Fri Dec 03 2004 - 12:00:06 EST