+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
+using @option{-h}, e.g.@: @code{pintos -h}.
+
+@node Debugging versus Testing
+@subsection Debugging versus Testing
+
+When you're debugging code, it's useful to be able 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, and that's the way that @command{pintos} invokes it
+by default.
+
+Of course, a simulation can only be reproducible from one run to the
+next if its input is the same each time. For simulating an entire
+computer, as we do, this means that every part of the computer must be
+the same. For example, you must use the same command-line argument, the
+same disks, the same version
+of Bochs, and you must not hit any keys on the keyboard (because you
+could not be sure to hit them at exactly the same point each time)
+during the runs.
+
+While reproducibility is useful for debugging, it is a problem for
+testing thread synchronization, an important part of most of the projects. In
+particular, when Bochs is set up for reproducibility, timer interrupts
+will come at perfectly reproducible points, and therefore so will
+thread switches. That means that running the same test several times
+doesn't give you any greater confidence in your code's correctness
+than does running it only once.
+
+So, to make your code easier to test, we've added a feature, called
+``jitter,'' to Bochs, that makes timer interrupts come at random
+intervals, but in a perfectly predictable way. In particular, if you
+invoke @command{pintos} with the option @option{-j @var{seed}}, timer
+interrupts will come at irregularly spaced intervals. Within a single
+@var{seed} value, execution will still be reproducible, but timer
+behavior will change as @var{seed} is varied. Thus, for the highest
+degree of confidence you should test your code with many seed values.
+
+On the other hand, when Bochs runs in reproducible mode, timings are not
+realistic, meaning that a ``one-second'' delay may be much shorter or
+even much longer than one second. You can invoke @command{pintos} with
+a different option, @option{-r}, to set up Bochs for realistic
+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.
+
+On the Linux machines only, 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
+only supports real-time simulation and does not have a reproducible
+mode.
+
+@node Grading
+@section Grading
+
+We will grade your assignments based on test results and design quality,
+each of which comprises 50% of your grade.
+
+@menu
+* Testing::
+* Design::
+@end menu
+
+@node Testing
+@subsection Testing
+
+Your test result grade will be based on our tests. Each project has
+several tests, each of which has a name beginning with @file{tests}.
+To completely test your submission, invoke @code{make check} from the
+project @file{build} directory. This will build and run each test and
+print a ``pass'' or ``fail'' message for each one. When a test fails,
+@command{make check} also prints some details of the reason for failure.
+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.
+
+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
+output as ``pass'' or ``fail'' and writes the verdict to
+@file{@var{t}.result}. To run and grade a single test, @command{make}
+the @file{.result} file explicitly from the @file{build} directory, e.g.@:
+@code{make tests/threads/alarm-multiple.result}. If @command{make} says
+that the test result is up-to-date, but you want to re-run it anyway,
+either run @code{make clean} or delete the @file{.output} file by hand.
+
+By default, each test provides feedback only at completion, not during
+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.
+
+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
+directory by a pristine, unmodified copy, to ensure that the correct
+tests are used. Thus, you can modify some of the tests if that helps in
+debugging, but we will run the originals.
+
+All software has bugs, so some of our tests may be flawed. If you think
+a test failure is a bug in the test, not a bug in your code,
+please point it out. We will look at it and fix it if necessary.
+
+Please don't try to take advantage of our generosity in giving out our
+test suite. Your code has to work properly in the general case, not
+just for the test cases we supply. For example, it would be unacceptable
+to explicitly base the kernel's behavior on the name of the running
+test case. Such attempts to side-step the test cases will receive no
+credit. If you think your solution may be in a gray area here, please
+ask us about it.
+
+@node Design
+@subsection Design
+
+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.
+
+We provide a design document template for each project. For each
+significant part of a project, the template asks questions in four
+areas: data structures, algorithms, synchronization, and rationale. An
+incomplete design document or one that strays from the template without
+good reason may be penalized. Incorrect capitalization, punctuation,
+spelling, or grammar can also cost points. @xref{Project
+Documentation}, for a sample design document for a fictitious project.
+
+Design quality will also be judged based on your source code. We will
+typically look at the differences between the original Pintos source
+tree and your submission, based on the output of a command like
+@code{diff -urpb pintos.orig pintos.submitted}. We will try to match up your
+description of the design with the code submitted. Important
+discrepancies between the description and the actual code will be
+penalized, as will be any bugs we find by spot checks.
+
+The most important aspects of design quality are those that specifically
+relate to the operating system issues at stake in the project. For
+example, the organization of an inode is an important part of file
+system design, so in the file system project a poorly designed inode
+would lose points. Other issues are much less important. For
+example, multiple Pintos design problems call for a ``priority
+queue,'' that is, a dynamic collection from which the minimum (or
+maximum) item can quickly be extracted. Fast priority queues can be
+implemented many ways, but we do not expect you to build a fancy data
+structure even if it might improve performance. Instead, you are
+welcome to use a linked list (and Pintos even provides one with
+convenient functions for sorting and finding minimums and maximums).
+
+Pintos is written in a consistent style. Make your additions and
+modifications in existing Pintos source files blend in, not stick out.
+In new source files, adopt the existing Pintos style by preference, but
+make the self-consistent at the very least. Use horizontal and vertical
+white space to make code readable. Add a comment to every structure,
+structure member, global or static variable, and function definition.
+Update existing comments as you modify code. Don't comment out or use
+the preprocessor to ignore blocks of code. Use assertions to document
+key invariants. Decompose code into functions for clarity. Code that
+is difficult to understand because it violates these or other ``common
+sense'' software engineering practices will be penalized.
+
+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
+
+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.
+
+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
+solutions available online or elsewhere. Reading the source code for
+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
+
+Pintos and this documentation were written by Ben Pfaff
+@email{blp@@cs.stanford.edu}.
+
+The original structure and form of Pintos was inspired by the Nachos
+instructional operating system from the University of California,
+Berkeley. A few of the source files were originally more-or-less
+literal translations of the Nachos C++ code into C. These files bear
+the original UCB license notice.
+
+A few of the Pintos source files are derived from code used in the
+Massachusetts Institute of Technology's 6.828 advanced operating systems
+course. These files bear the original MIT license notice.
+
+The Pintos projects and documentation originated with those designed for
+Nachos by current and former CS140 teaching assistants at Stanford
+University, including at least Yu Ping, Greg Hutchins, Kelly Shaw, Paul
+Twohey, Sameer Qureshi, and John Rector. If you're not on this list but
+should be, please let me know.
+
+Example code for condition variables (@pxref{Condition Variables}) is
+from classroom slides originally by Dawson Engler and updated by Mendel
+Roseblum.
+
+@node Trivia
+@section Trivia
+
+Pintos originated as a replacement for Nachos with a similar design.
+Since then Pintos has greatly diverged from the Nachos design. Pintos
+differs from Nachos in two important ways. First, Pintos runs on real
+or simulated 80@var{x}86 hardware, whereas Nachos runs as a process on a
+host operating system. Second, like most real-world operating systems,
+Pintos is written in C, whereas Nachos is written in C++.
+
+Why the name ``Pintos''? First, like nachos, pinto beans are a common
+Mexican food. Second, Pintos is small and a ``pint'' is a small amount.
+Third, like drivers of the eponymous car, students are likely to have
+trouble with blow-ups.
projects / pintos-anon / blobdiff