Update docs.
authorBen Pfaff <blp@cs.stanford.edu>
Thu, 16 Sep 2004 06:40:16 +0000 (06:40 +0000)
committerBen Pfaff <blp@cs.stanford.edu>
Thu, 16 Sep 2004 06:40:16 +0000 (06:40 +0000)
doc/threads.texi
doc/userprog.texi

index 7f9c975e5cdb0477c5e3feff12a58acfa86dd9ad..168ee79ca7e054e6a33f55a07c254becb77034f4 100644 (file)
@@ -13,6 +13,7 @@ side.  Compilation should be done in the @file{threads} directory.
 
 @menu
 * Understanding Threads::       
+* Project 1 Code::              
 * Debugging versus Testing::    
 * Tips::                        
 * Problem 1-1 Alarm Clock::     
@@ -87,6 +88,94 @@ in @file{threads/malloc.c}.  Note that the page allocator doles out
 limit.  If you need larger chunks, consider using a linked structure
 instead.
 
+@node Project 1 Code
+@section Code
+
+Here is a brief overview of the files in the @file{threads}
+directory.  You will not need to modify most of this code, but the
+hope is that presenting this overview will give you a start on what
+code to look at.
+
+@table @file
+@item loader.S
+@itemx loader.h
+The kernel loader.  Assembles to 512 bytes of code and data that the
+PC BIOS loads into memory and which in turn loads the kernel into
+memory, does basic processor initialization, and jumps to the
+beginning of the kernel.  You should not need to look at this code or
+modify it.
+
+@item kernel.lds.S
+The linker script used to link the kernel.  Sets the load address of
+the kernel and arranges for @file{start.S} to be at the very beginning
+of the kernel image.  Again, you should not need to look at this code
+or modify it, but it's here in case you're curious.
+
+@item start.S
+Jumps to @code{main()}.
+
+@item init.c
+@itemx init.h
+Kernel initialization, including @code{main()}, the kernel's ``main
+program.''  You should look over @code{main()} at least to see what
+gets initialized.
+
+@item thread.c
+@itemx thread.h
+Basic thread support.  Much of your work will take place in these
+files.  @file{thread.h} defines @code{struct thread}, which you will
+modify in the first three projects.
+
+@item switch.S
+@itemx switch.h
+Assembly language routine for switching threads.  Already discussed
+above.
+
+@item palloc.c
+@itemx palloc.h
+Page allocator, which hands out system memory one 4 kB page at a time.
+
+@item paging.c
+@itemx paging.h
+Initializes the kernel page table.  FIXME
+
+@item malloc.c
+@itemx malloc.h
+A very simple implementation of @code{malloc()} and @code{free()} for
+the kernel.  The largest block that can be allocated is 2 kB.
+
+@item interrupt.c
+@itemx interrupt.h
+Basic interrupt handling and functions for turning interrupts on and
+off.
+
+@item intr-stubs.pl
+@itemx intr-stubs.h
+A Perl program that outputs assembly for low-level interrupt handling.
+
+@item synch.c
+@itemx synch.h
+Basic synchronization primitives: semaphores, locks, and condition
+variables.  You will need to use these for synchronization through all
+four projects.
+
+@item test.c
+@itemx test.h
+Test code.  For project 1, you will replace this file with your test
+cases.
+
+@item io.h
+Functions for I/O port access.  This is mostly used by source code in
+the @file{devices} directory that you won't have to touch.
+
+@item mmu.h
+Functions and macros related to memory management, including page
+directories and page tables.  This will be more important to you in
+project 3.  For now, you can ignore it.
+@end table
+
+
+
 @node Debugging versus Testing
 @section Debugging versus Testing
 
@@ -162,7 +251,7 @@ such that you have Problem 3 fully working before you begin to tackle
 Problem 4.
 
 @node Problem 1-1 Alarm Clock
-@section Problem 1-2: Alarm Clock
+@section Problem 1-1: Alarm Clock
 
 Improve the implementation of the timer device defined in
 @file{devices/timer.c} by reimplementing @code{timer_sleep()}.
index 361c1a47026d2e3db14033d6863d64e2a92bc7c1..14a282d3463686004db353a89185905ddd89c149 100644 (file)
@@ -33,12 +33,11 @@ this illusion.
 FIXME
 Before we delve into the details of the new code that you'll be
 working with, you should probably undo the test cases from project 1.
-All you need to do is make sure the original
-@file{threads/pintostest.c} is in place.  This will stop the tests
-from being run.
+All you need to do is make sure the original @file{threads/test.c} is
+in place.  This will stop the tests from being run.
 
 @menu
-* Project 2 Code to Hack::      
+* Project 2 Code::              
 * Using the File System::       
 * How User Programs Work::      
 * Global Requirements::         
@@ -49,8 +48,8 @@ from being run.
 * System Calls::                
 @end menu
 
-@node Project 2 Code to Hack
-@section Code to Hack
+@node Project 2 Code
+@section Code
 
 The easiest way to get an overview of the programming you will be
 doing is to simply go over each part you'll be working with.  In
@@ -128,7 +127,7 @@ of the file system routines now will make life much easier for project
 
 You need to be able to create and format simulated disks.  The
 @command{pintos} program provides this functionality with its
-@option{make-disk} command.  From the @filesys{build} directory,
+@option{make-disk} command.  From the @file{filesys/build} directory,
 execute @code{pintos make-disk fs.dsk 2}.  This command creates a 2 MB
 simulated disk named @file{fs.dsk}.  (It does not actually start
 Pintos.)  Then format the disk by passing the @option{-f} option to