Replace GSX Server support with VMware Player support.
[pintos-anon] / doc / intro.texi
index f563dac817fbf9628081a84efb36f999dea060c3..a74ce8297c91009dad4fa423531a7fee707f613c 100644 (file)
@@ -17,8 +17,7 @@ systems and software can run under it.  In class we will use the
 @uref{http://bochs.sourceforge.net, , Bochs} and 
 @uref{http://fabrice.bellard.free.fr/qemu/, ,
 qemu} simulators.  Pintos has also been tested with
-@uref{http://www.vmware.com/products/server/gsx_features.html, ,
-VMware GSX Server}.
+@uref{http://www.vmware.com/, , VMware Player}.
 
 These projects are hard.  CS 140 has a reputation of taking a lot of
 time, and deservedly so.  We will do what we can to reduce the workload, such
@@ -35,7 +34,7 @@ projects.
 @menu
 * Getting Started::             
 * Grading::                     
-* License::                     
+* Legal and Ethical Issues::    
 * Acknowledgements::            
 * Trivia::                      
 @end menu
@@ -239,7 +238,8 @@ read.  However, you've probably noticed by now that the same text was
 displayed in the terminal you used to run @command{pintos}.  This is
 because Pintos sends all output both to the VGA display and to the first
 serial port, and by default the serial port is connected to Bochs's
-@code{stdout}.  You can log this output to a file by redirecting at the
+@code{stdin} and @code{stdout}.  You can log serial output to a file by
+redirecting at the
 command line, e.g.@: @code{pintos run alarm-multiple > logfile}.
 
 The @command{pintos} program offers several options for configuring the
@@ -254,8 +254,8 @@ with a debugger (@pxref{GDB}).  You can set the amount of memory to give
 the VM.  Finally, you can select how you want VM output to be displayed:
 use @option{-v} to turn off the VGA display, @option{-t} to use your
 terminal window as the VGA display instead of opening a new window
-(Bochs only), or @option{-s} to suppress the serial output to
-@code{stdout}.
+(Bochs only), or @option{-s} to suppress serial input from @code{stdin}
+and output to @code{stdout}.
 
 The Pintos kernel has commands and options other than @command{run}.
 These are not very interesting for now, but you can see a list of them
@@ -268,8 +268,8 @@ When you're debugging code, it's useful to be able to run a
 program twice and have it do exactly the same thing.  On second and
 later runs, you can make new observations without having to discard or
 verify your old observations.  This property is called
-``reproducibility.''  The simulator we use by default, Bochs, can be set
-up for
+``reproducibility.''  One of the simulators that Pintos supports, Bochs,
+can be set up for
 reproducibility, and that's the way that @command{pintos} invokes it
 by default.
 
@@ -337,7 +337,10 @@ After running all the tests, @command{make check} also prints a summary
 of the test results.
 
 For project 1, the tests will probably run faster in Bochs.  For the
-rest of the projects, they will probably run faster in qemu.
+rest of the projects, they will run much faster in qemu.
+@command{make check} will select the faster simulator by default, but
+you can override its choice by specifying @option{SIMULATOR=--bochs} or
+@option{SIMULATOR=--qemu} on the @command{make} command line.
 
 You can also run individual tests one at a time.  A given test @var{t}
 writes its output to @file{@var{t}.output}, then a script scores the
@@ -353,8 +356,8 @@ its run.  If you prefer, you can observe the progress of each test by
 specifying @option{VERBOSE=1} on the @command{make} command line, as in
 @code{make check VERBOSE=1}.  You can also provide arbitrary options to the
 @command{pintos} run by the tests with @option{PINTOSOPTS='@dots{}'},
-e.g.@: @code{make check PINTOSOPTS='--qemu'} to run the tests under
-qemu.
+e.g.@: @code{make check PINTOSOPTS='-j 1'} to select a jitter value of 1
+(@pxref{Debugging versus Testing}).
 
 All of the tests and related files are in @file{pintos/src/tests}.
 Before we test your submission, we will replace the contents of that
@@ -499,12 +502,15 @@ In the end, remember your audience.  Code is written primarily to be
 read by humans.  It has to be acceptable to the compiler too, but the
 compiler doesn't care about how it looks or how well it is written.
 
-@node License
-@section License
+@node Legal and Ethical Issues
+@section Legal and Ethical Issues
 
 Pintos is distributed under a liberal license that allows free use,
 modification, and distribution.  Students and others who work on Pintos
 own the code that they write and may use it for any purpose.
+Pintos comes with NO WARRANTY, not even for MERCHANTABILITY or FITNESS
+FOR A PARTICULAR PURPOSE.
+@xref{License}, for details of the license and lack of warranty.
 
 In the context of Stanford's CS 140 course, please respect the spirit
 and the letter of the honor code by refraining from reading any homework
@@ -513,12 +519,6 @@ other operating system kernels, such as Linux or FreeBSD, is allowed,
 but do not copy code from them literally.  Please cite the code that
 inspired your own in your design documentation.
 
-Pintos comes with NO WARRANTY, not even for MERCHANTABILITY or FITNESS
-FOR A PARTICULAR PURPOSE.
-
-The @file{LICENSE} file at the top level of the Pintos source
-distribution has full details of the license and lack of warranty.
-
 @node Acknowledgements
 @section Acknowledgements
 
@@ -542,7 +542,7 @@ Nachos by current and former CS 140 teaching assistants at Stanford
 University, including at least Yu Ping, Greg Hutchins, Kelly Shaw, Paul
 Twohey, Sameer Qureshi, and John Rector.
 
-Example code for condition variables (@pxref{Condition Variables}) is
+Example code for monitors (@pxref{Monitors}) is
 from classroom slides originally by Dawson Engler and updated by Mendel
 Rosenblum.