\title{
\includegraphics[height=1.5in]{v3vee.pdf}
-\includegraphics[height=1.5in]{palacios.pdf} \\
+\includegraphics[height=1.5in]{logo6.png} \\
\vspace{0.5in}
Palacios Internal Developer Manual
}
-\author{Jack Lange \hspace{0.5in} Lei Xia}
+\author{Jack Lange}
\maketitle
-\section{Organization}
+This manual is written for Internal Palacios developers. It contains
+information on how to obtain the palacios code base, how to go about
+the development process, and how to commit those changes to the
+mainline source tree. This assumes that the reader has read {\em An
+Introduction to the Palacios Virtual Machine Monitor -- Release 1.0}
+and also has a slight working knowledge of {\em git}.
+
+
+\section{Overview}
+
+
+Both Palacios and Kitten follow a hybrid development process that
+uses both the centralized repository and distributed development
+models. A central repository exists that holds the master version of
+the code base. This central repository is cloned by multiple people
+and in multiple places to support various development efforts. A
+feature of git is that every developer actually has a fully copy of
+the entire repository, and so can function independently until such
+time as they need to resync with the master version.
+
+There are typically multiple levels of access to the central
+repository, that are granted based on the type of developer being
+granted access. The three basic developer types and their access
+privileges are:
+
+\begin{itemize}
+\item Core Developers: These are the lead developers and are in
+charge of managing the master repository. They have full read/write
+access permissions to the central repository.
+
+\item Internal Developers: Formal members of the development
+team. These people are capable of pulling directly from the central
+repository, but lack the ability to write directly to it.
+
+\item External Developers: People who are not actual members of the
+development team. These people can only access the public repository
+which is only updated to contain the release versions.
+\end{itemize}
+
+Because internal and external developers cannot write directly to the
+master repository, they need to first submit their changes to a core
+developer before they can be added to the mainline. We will discuss
+that process in Section~\ref{sec:submission}.
\section{Checking out Palacios}
+The central palacios repository is located on {\em
+newskysaw.cs.northwestern.edu} in {\em /home/palacios/palacios}. All
+internal developers have read access to the directory. Each developer
+must create their own local version of the repository, this is done
+with {\em git clone}.
+
+\begin{verbatim}
+git clone /home/palacios/palacios
+\end{verbatim}
+
+This creates a local copy of the repository at {\em ./palacios/}.
+
+
+All development work is done in the {\em devel} branch of the
+repository. The developer can access this branch via:
+
+\begin{verbatim}
+git checkout --track -b devel origin/devel
+\end{verbatim}
+
+or
+
+\begin{verbatim}
+/opt/vmm-tools/bin/checkout_branch devel
+\end{verbatim}
+
+{\em Important:}
+Note that palacios is very actively developed so the contents of the
+{\em devel} branch are frequently changing. In order to keep up to
+date with the latest version, it is necessary to periodically pull the
+latest changes from the master repository by running \verb.git pull..
-Checkout or clone the devel branch of Palacios from the master
-repository. You should have the read permission to these branches.
\section{Checking out Kitten}
-hg clone /home/palacios/kitten
+Kitten is available from Sandia National Labs, and is the main host OS
+we are targetting with Palacios. Loosely speaking core Palacios
+developers are internal Kitten developers, and internal Palacios
+developers are external Kitten developers. Because we have limited
+access to the Kitten repository, we are maintaining a local mirror
+copy in {\em /home/palacios/kitten}.
-git clone /home/palacios/palacios
+Kitten uses Mercurial for their source management, so you will have to
+make sure the local mercurial version is configured correctly.
+Specifically you should add the following python path to your shell environment.
-/opt/vmm-tools/bin/checkout\_branch devel
+\begin{verbatim}
+export PYTHONPATH=/usr/local/lib64/python2.4/site-packages/
+\end{verbatim}
+
+You can then clone Kitten from the local mirror:
+\begin{verbatim}
+hg clone /home/palacios/kitten
+\end{verbatim}
+{\em Important:} Like Palacios, Kitten is very actively developed so
+source tree is frequently changing. In order to keep up to date with
+the latest version, it is necessary to periodically pull the latest
+changes from the mirror repository by running \verb.hg pull. followed
+by \verb.hg update..
+
\section{Compiling Palacios}
cd palacios/build/
\section{Running Palacios/Kitten}
Run the whole stuff built above in Qemu using following command:
-/usr/local/qemu/bin/qemu-system-x86\_64 -smp 1 -m 1024 -serial file:./serial.out -cdrom ./arch/x86\_64/boot/image.iso -net tap, ifname=tap0 < /dev/null
+\begin{verbatim}
+/usr/local/qemu/bin/qemu-system-x86_64 -smp 1 -m 1024
+ -serial file:./serial.out
+ -cdrom ./arch/x86_64/boot/image.iso
+ -net tap, ifname=tap0
+ < /dev/null
+\end{verbatim}
+
+
+
+\section{Development Guidelines}
+32/64 bit compatibility
+name space
+coding guidelines
-\section{networking}
+
+\section{Code Submission}
+\label{sec:submission}
+\subsection{Palacios}
+
+\includegraphics[height=3.5in]{dev_chart.pdf}
+
+stacked git
+
+\subsection{Kitten}
+
+mercurial queues
+
+\section{Networking}
\section{Configuring the development host's Qemu network}
Set up Tap interfaces:
+
+
For more questions, talk to Jack or Lei.
\end{document}
