pintos-os.org Git - pintos-anon/blob - sigcse2009/introduction.tex

   1 \section{Introduction}
   2 \label{sec:intro}
   3
   4 Despite the wide use of higher-level languages and environments, gaining a robust
   5 understanding of operating systems (OS) fundamentals and training in the current design and
   6 implementation practices of OS remains a cornerstone of
   7 undergraduate computer science education.
   8
   9 % abstract/concrete
  10 % internal/external
  11 Approaches to teaching OS courses generally fall along two axes:
  12 whether the treatment of the material is abstract or
  13 concrete~\cite{Hovemeyer2004Running}, and whether they adopt an
  14 internal or external perspective~\cite{Deitel2003Operating}.
  15 An abstract approach discusses algorithms and techniques used in operating
  16 systems and may include partial implementation or simulation exercises,
  17 whereas a concrete approach stresses the design and creation of
  18 realistic artifacts.
  19 When adopting the internal perspective, an operating system is considered
  20 from the point of view of the OS designer, whereas the external perspective
  21 assumes the role of a user or programmer using an OS's
  22 facilities~\cite{Bryant2002Computer}.
  23
  24 % we don't really say about the benefits of the 'internal' approach here.
  25 % is this too controversial for this audience?
  26 The approach advocated in this paper is concrete and adopts the internal perspective.
  27 Students who have studied, implemented, and evaluated core OS techniques attain
  28 a deeper understanding than those who have merely studied them.
  29 Finally, adopting a concrete approach brings significant secondary
  30 benefits, including training in modern software development techniques
  31 and tools.  The C language remains the implementation language of choice
  32 for operating system kernels and for many embedded systems.
  33 Practice and debugging experience in C, particularly using modern tools,
  34 not only increases students' ``market value,''~\cite{1292450} but provides students with
  35 the insight that a low-level programming and runtime model is not incompatible
  36 with high-level tools.
  37
  38 Designing course material for the internal and concrete
  39 approach is challenging.  While realistic,
  40 assignments should be relatively simple and doable within a realistic time frame.
  41 Whereas assignments should use current hardware architectures,
  42 they must not impart too much transient knowledge.
  43 Assignments should include and emphasize the use of modern software
  44 engineering practices and tools, such as dynamic program analysis.
  45
  46 This paper introduces Pintos, an instructional operating system kernel that
  47 has been in use at multiple institutions for about 4 years.  Pintos provides
  48 a bootable kernel for standard x86-based personal computers.  We provide four
  49 structured assignments in which students implement a basic priority
  50 scheduler, a multi-level feedback queue scheduler, a process-based
  51 multi-programming system, page-based virtual memory
  52 including on-demand paging, memory-mapped files, and swapping, and a
  53 simple hierarchical file system.  An overview of the projects enabled
  54 by Pintos is given in Figure~\ref{fig:pintosdetail}, which shows which
  55 software is provided as support code and test cases,
  56 the parts that are created by students, and their relationship.
  57
  58 Although Pintos follows in the tradition of instructional operating systems
  59 such as Nachos~\cite{Christopher1993Nachos}, OS/161~\cite{Holland2002New}, and
  60 GeekOS~\cite{Hovemeyer2004Running},
  61 PortOS~\cite{Atkin2002PortOS},
  62 BLITZ~\cite{PorterOverview},
  63 JOS~\cite{1088822}, or Yalnix~\cite{1088822},
  64 we believe that it is unique in two
  65 aspects.  First, Pintos runs on both real hardware and in emulated and
  66 simulated environments.\footnote{\small GeekOS is the only other system that claims to
  67 also run on real PC hardware; it requires, however, a dedicated disk and
  68 does not support running off USB devices, making it impractical for many
  69 laboratory settings.}  We believe that having the ability to see the outcome
  70 of their project interact with actual hardware increases student engagement.
  71 Second, we have created a set of analysis tools
  72 for the emulated environment that allows students to detect programming
  73 mistakes such as race conditions.  Figure~\ref{fig:pintosenvs} shows
  74 the three environments in which the same kernel can be run.
  75
  76 Others have used Linux, either on dedicated devices (e.g., iPodLinux~\cite{1352199}),
  77 or in virtualized environments~\cite{1008027,1352648,Nieh2005Experiences}, to provide
  78 an internal, concrete perspective.  Compared to those approaches, Pintos provides
  79 a similar level of realism in that students can see the results of their
  80 work on concrete or virtualized hardware, but does not require that students
  81 understand the often arcane and ill-documented interfaces of the Linux kernel,
  82 which were not designed from an educational perspective.
  83 By contrast, all Pintos code is written to be studied by students.
  84
  85 %This paper summarizes the design philosophy that underlies Pintos,
  86 %details its structure, and outlines the nature and learning goals of each
  87 %assignment.
  88
  89 \pintosenvfigure{}
  90
  91 \pintosdetailfiguretwo{}
  92
  93 % Challenges.
  94 % How to embed principles?
  95 % How to teach software engineering?
  96 % Realism vs. Simplification
  97
  98 %User-Mode Linux\cite{1008027}
  99 %Virtualization\cite{1352648}
 100 %Linux in VM\cite{Nieh2005Experiences}
 101