README.STARTING_P3

0. Introduction

This readme contains some build instrucions and some notes on the layout
of this directory structure.

1. Using your P1 code in P3

We have given you kern/fake_console.c and kern/inc/console.h.
In order for the stdio library to print things, it must
be able to "find" putbytes() and putbyte(), which must
be defined by console.h.  The source for those of course
need not be in a file called "fake_console.c"!

The exact interfaces between your kernel code and your P1
console, timer, and keyboard are up to you--function names
can change if appropriate, etc.

2. Build Process

The build process for this project is somewhat complicated but
it should be easy for you to get it to do things you're supposed
to get it to do.

In the top-level directory there is a file called config.mk.

  UPDATE_METHOD should be left as "afs" if possible.

  410KERNEL_OBJS builds files from 410kern/ into your kernel.
  KERNEL_OBJS builds files from kern/ into your kernel.

  410REQPROGS builds files from 410user/progs into your kernel's
  RAM-disk file system.  It is VERY IMPORTANT that you list here
  only files which must be present for your kernel to boot (e.g.,
  idle, init, shell).  DO NOT INCLUDE ANY TEST PROGRAMS IN
  410REQPROGS.

  STUDENTREQPROGS builds files from 410user/progs into your kernel's
  RAM-disk file system.  It is VERY IMPORTANT that you list here
  only files which must be present for your kernel to boot.
  DO NOT INCLUDE ANY TEST PROGRAMS IN STUDENTREQPROGS.

  410TESTS and STUDENTTESTS specify which OPTIONAL programs
  from {410user/progs,user/progs}, respectively, will be built
  into your kernel's RAM-disk file system.  If you want to write
  a test program called "test", put test.c into user/progs and
  put "test" into STUDENTTESTS.  Before we grade your kernel,
  we will overwrite the values of 410TESTS and STUDENTTESTS.
  If either one contains the name of a program your kernel
  needs to operate properly, you will fail the entire test
  suite.

  THREAD_OBJS and SYSCALL_OBJS are the names of object (.o) files
  in the user/lib{thread,syscall} directories, respectively,
  which you wish to be built into libthread.a and libsyscall.a.

When we grade your submission we will depend on THREAD_OBJS and
SYSCALL_OBJS being correct and we will override the values of
410PROGS and STUDENTPROGS.

If you feel you need to edit one or more Makefiles, you should
probably stop and consult the course staff.  Before building
and grading your submission, we will wipe out any Makefile
changes which haven't been cleared...

3. Getting started

This tarball contains a fake Makefile.  If the update
method setting in config.mk is ok, typing "make" should
populate the directory tree and build a "kernel" which
when booted does nothing but print out a greeting to
the simics log.

4. Directory Structure

./
  The only files you should ever even think about editing in the 
  top-level directory is config.mk.

./410kern
  We have placed some useful support code here (libraries and
  include files).  Please don't put anything here yourselves.

./kern
  Your mission, since you have chosen to accept it, will be to
  fill in this directory with a kernel implementation.  Good luck!

./user/inc, ./user/libsyscall, ./user/libthread
  You will probably wish to populate these directories with your
  Project 2 files.

./user/progs
  This is where you should put the source files for your tests.
  You should not have to edit the Makefile. You should add your
  tests to config.mk.

./410user/progs
  This is where we will stick our tests.  Don't touch this directory.

./temp
  This is a directory where some temp files will go during the build
  process that makes the RAM disk.  You should not have to touch this
  directory.

./vq_challenge
  This directory contains details of a totally-optional challenge you
  may wish to take on, namely using macros to generate embedded
  linked-list traversal declarations and code.  You really don't have
  to do this, but you might like the results.