From cfd2d6559ef64e7fbcfd8b0330a78c48bee849d3 Mon Sep 17 00:00:00 2001 From: Ben Pfaff Date: Thu, 16 Sep 2004 06:40:16 +0000 Subject: [PATCH] Update docs. --- doc/threads.texi | 91 ++++++++++++++++++++++++++++++++++++++++++++++- doc/userprog.texi | 13 ++++--- 2 files changed, 96 insertions(+), 8 deletions(-) diff --git a/doc/threads.texi b/doc/threads.texi index 7f9c975..168ee79 100644 --- a/doc/threads.texi +++ b/doc/threads.texi @@ -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()}. diff --git a/doc/userprog.texi b/doc/userprog.texi index 361c1a4..14a282d 100644 --- a/doc/userprog.texi +++ b/doc/userprog.texi @@ -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 -- 2.30.2