1 \section{Design Principles}
2 \label{sec:designprinciples}
4 The Pintos series of projects are built on a number of principles.
6 \paragraph{Read before You code.}
7 Each project involves a significant amount of reading code before
8 students write the first line of their code.
9 Because software maintenance constitutes the vast majority of all
10 software development efforts~\cite{Boehm1981Software}, this setup mirrors the
11 environment in which most software engineers work.
12 We went to great lengths to write the entire Pintos baseline code,
13 and in particular the portions students will read, in a style that shows,
14 by example, the coding style we expect from students. This style
15 includes purely syntactical convention such as the choice of the
16 GNU indentation style, and extends to commenting style and naming
17 conventions. During the semesters in which Pintos was used, we
18 continuously refined the internal code documentation, focusing on those
19 portions that initially proved difficult to understand or confusing.
21 \paragraph{Maximize Creative Freedom}
22 OS design involves a tremendous amount of creative freedom, both in the
23 choice of algorithm and data structures. Our projects are designed to
24 stimulate creativity by avoiding the prescription of specific approaches
25 to accomplish each project's goals. Instead, students must design their
26 own data structures and associated algorithms as much as possible.
28 \paragraph{Practice Test-driven Development}
29 %Test-driven development~\cite{Edwards}
30 Each project includes a large number of test cases that is accessible
32 They must implement the API that is exercised by these test cases.
33 Students are encouraged to add their own test cases.
35 \paragraph{Work in a Team}
36 The projects presented in this paper are designed to be accomplished by teams of
37 2-4 students. Working in a team provides an environment that more closely resembles
38 industrial software development, and it provides a way for students brainstorm and
39 implement together. In addition, we teach and require the use of group collaboration tools,
40 notably shared source code version control systems such as CVS.
42 \paragraph{Justify your Design}
43 Design justification and rationale is as important for learning as creating an artifact
44 that fulfill a set of given requirements. We designed a set of structured questionnaires
45 in which students describe their design and discuss choices and trade-offs they made.
47 \paragraph{Provide a Reproducible, Manageable Environment}
48 Operating Systems are inherently concurrent environments, which can be difficult
49 to debug. For educational use, we must provide an environment that is
50 manageable and reproducible, which is given by the option
51 of running Pintos in a simulated environment eliminates this
52 non-determinism. As a result, Pintos kernels can be debugged in a manner that
53 is substantially similar to how user programs are being debugged.
55 \paragraph{Include Analysis Tools}
56 Static and dynamic analysis tools are now widely being used; an OS course should
57 be no exception. We have extended the Qemu emulator that perform tailored
58 analyses that can point out errors such as race conditions.
60 \paragraph{Provide Extensive and Structured Documentation}
61 Instructional systems often are not shared, or fall in disuse because the expertise to use them
62 in a teaching setting relies on too much undocumented knowledge, making training of
63 teaching assistants difficult and providing a steep learning curve for instructors
64 wishing to use. Pintos includes an extensive 129 page manual, a sample solution,
65 and instructions for teaching assistants. The assignment documentation separates those parts
66 students must read from those parts that merely provide supplemental information.
67 %Even though Pintos uses an existing and complex architecture, our experience indicates
68 %that the manual is sufficient for most students.
projects / pintos-anon / blob