X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fintro.texi;h=ede0a69b58fccc85b6fc9a6cc33fb08dffc678ef;hb=d4711f749a61550fc1e64e2f78af1e8827b92de3;hp=6541cf1b903f5a46f141da68af72a7f68310da90;hpb=837e5b7fb902bd749106309ef76a5276c73ca34c;p=pintos-anon diff --git a/doc/intro.texi b/doc/intro.texi index 6541cf1..ede0a69 100644 --- a/doc/intro.texi +++ b/doc/intro.texi @@ -16,9 +16,8 @@ CPU and its peripheral devices accurately enough that unmodified operating 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}. +QEMU} simulators. Pintos has also been tested with +@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 @@ -50,8 +49,9 @@ Stanford ITSS, as described on the @uref{http://www.stanford.edu/services/cluster/environs/sweet/, , ITSS webpage}. You may use the Solaris or Linux machines. We will test your code on these machines, and the instructions given here assume this -environment. However, Pintos and its supporting tools are portable -enough that it should build ``out of the box'' in other environments. +environment. We cannot provide support for installing and working on +Pintos on your own machine, but we provide instructions for doing so +nonetheless (@pxref{Installing Pintos}). Once you've logged into one of these machines, either locally or remotely, start out by adding our binaries directory to your @env{PATH} @@ -82,7 +82,7 @@ you log in. Now you can extract the source for Pintos into a directory named @file{pintos/src}, by executing @example -tar xzf /usr/class/cs140/pintos/pintos.tar.gz +zcat /usr/class/cs140/pintos/pintos.tar.gz | tar x @end example Alternatively, fetch @uref{http://@/www.stanford.edu/@/class/@/cs140/@/pintos/@/pintos.@/tar.gz} @@ -250,7 +250,7 @@ from them by @option{--}, so that the whole command looks like @code{pintos @var{option}@dots{} -- @var{argument}@dots{}}. Invoke @code{pintos} without any arguments to see a list of available options. Options can select a simulator to use: the default is Bochs, but -@option{--qemu} selects qemu. You can run the simulator +@option{--qemu} selects QEMU. You can run the simulator 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 @@ -308,9 +308,9 @@ timings, in which a one-second delay should take approximately one second of real time. Simulation in real-time mode is not reproducible, and options @option{-j} and @option{-r} are mutually exclusive. -The qemu simulator is available as an +The QEMU simulator is available as an alternative to Bochs (use @option{--qemu} when invoking -@command{pintos}). The qemu simulator is much faster than Bochs, but it +@command{pintos}). The QEMU simulator is much faster than Bochs, but it only supports real-time simulation and does not have a reproducible mode. @@ -338,7 +338,7 @@ 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 run much 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. @@ -358,7 +358,7 @@ 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='-j 1'} to select a jitter value of 1 -(@pxref{Debugging Versus Testing}). +(@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 @@ -385,7 +385,8 @@ We will judge your design based on the design document and the source code that you submit. We will read your entire design document and much of your source code. -Don't forget that the design document is 50% of your project grade. It +Don't forget that design quality, including the design document, is 50% +of your project grade. It is better to spend one or two hours writing a good design document than it is to spend that time getting the last 5% of the points for tests and then trying to rush through writing the design document in the last 15 @@ -491,7 +492,8 @@ make your code self-consistent at the very least. There should not be a patchwork of different styles that makes it obvious that three different people wrote the code. Use horizontal and vertical white space to make code readable. Add a brief comment on every structure, structure -member, global or static variable, and function definition. Update +member, global or static variable, typedef, enumeration, and function +definition. Update existing comments as you modify code. Don't comment out or use the preprocessor to ignore blocks of code (instead, remove it entirely). Use assertions to document key invariants. Decompose code into @@ -503,12 +505,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 @@ -517,12 +522,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