\section{Programs and Processes}
\begin{frame}
   {What is a Program?}

   \begin{itemize}
      \item A \textbf{program} is a set of instructions to
      be carried out (plus any data required to do so)
      \item May consist of machine level instructions run
      directly by a CPU
      \item May consist of a list of commands to be
      interpreted by another program
      \item Programmers use various languages (such as
      \textbf{C, C++, Perl}, and many more) to code
      instructions in a program
   \end{itemize}
   \begin{lfbox}[programs vs scripts]
      People often distinguish between programs, which are
      \textbf{compiled} into a binary executable form; and
      \textbf{scripts}, which need to be run by an
      interpreter such as \textbf{bash}, \textbf{Python} or
      \textbf{Perl}.
   \end{lfbox}

\end{frame}

\cprotect\note{

   A program is a set of instructions, along with any
   internal data used while carrying the instructions
   out.  Programs may also use external data..
   Internal data might include text strings inside the
   program which are used to display user prompts.
   External data might include data from a database.

   Many user commands such as \textbf{ls}, \textbf{cat},
   and \textbf{rm} are programs which are external to the
   operating system kernel, or shell (in other words they
   have their own executable program on disk).  }


\begin{frame}
   {What is a Process?}

   \begin{itemize}
      \item A \textbf{process} is a program being executed
      \item \textbf{Linux} creates a new process for every program
      that is executed or run
      \item Several processes may be executing the same
      program at the same time
      \item Primary purpose of the operating system is to
      manage the execution of processes on behalf of users

      \begin{info}[Multithreading]
         A program may be composed of multiple simultaneous
         \textbf{threads}, each of which is considered as
         its own process.
      \end{info}

   \end{itemize}

\end{frame}

\cprotect\note{

   A process is an instance of a program in execution. It
   may be in a number of different states, such as running
   or sleeping.

   Every process has a \textbf{pid} (Process ID), a
   \textbf{ppid} (Parent Process ID), and a \textbf{pgid}
   (Process Group ID). In addition every process has
   program code, data, variables, file descriptors, and an
   environment.

   Processes are controlled by \textbf{scheduling}, which
   is completely preemptive. Only the kernel has the right
   to preempt a process; they cannot do it to each other.

   For historical reasons, the largest \textbf{pid} has been
   limited to a 16-bit number, or 32768. It is possible to
   alter this value by changing
   \filelink{/proc/sys/kernel/pid_max}, since it may be
   inadequate for larger servers. As processes are created
   eventually they will reach \verb?pid_max?, at which
   point they will start again at \verb?PID = 300?.

}


\begin{frame}
   {Attributes of a Process}

   \begin{itemize}
      \item     All processes have certain attributes:
      \begin{itemize}
         \item The program being executed
         \item Context (state)
         \item Permissions
         \item Associated resources
      \end{itemize}
   \end{itemize}

\end{frame}

\cprotect\note{

   Every process is executing some program.  At any given
   moment, the process may take a snapshot of itself by
   trapping the state of its CPU registers, where it is
   executing in the program, what is in the process' memory,
   and other information.  This is the \textbf{context} of the process.

   Since processes can be scheduled in and out when sharing CPU
   time with others (or have to be put to sleep while waiting
   for some condition to be fulfilled, such as the user to make
   a request or data to arrive), being able to store the entire
   context when swapping out the process and being able to
   restore it upon execution resumption is critical to the
   kernel's ability to do \textbf{context switching}.


   Every process has permissions based on which user has called
   it to execute.  It may also have permissions based on who
   owns its program file.  Programs which are marked with an
   "s" execute bit have a different "effective" user id than
   their "real" user id.  These programs are referred to as
   setuid programs.  They run with the user-id of the user who
   owns the program, where a non-setuid program runs with the
   permissions of the user who starts it.  Setuid programs
   owned by root can be a security problem.

   The \textbf{passwd} program is an example of a setuid
   program.  It is runnable by any user.  When a user
   executes this program, the process runs with root
   permission in order to be able to update the
   write-restricted files, \filelink{/etc/passwd} and
   \filelink{/etc/shadow}, where the user passwords are
   maintained.

   Note that every process has resources such as allocated
   memory, file handles, etc.  }



\begin{frame}
   {Process Resource Isolation}

   \begin{itemize}
      \item Kernel isolates processes from each other (by
      default)
      \begin{itemize}
         \item Promotes security
         \item Increase stability
      \end{itemize}
      \item Kernel does not allow processes to access
      arbitrary hardware resources
      \begin{itemize}
         \item Access to hardware managed by kernel
         \item Access through \textbf{system calls}
      \end{itemize}
   \end{itemize}

\end{frame}

\cprotect\note{

   When a process is started it is isolated in its own user
   space to protect it from other processes.  This promotes
   security and creates greater stability.

   Processes do not have direct access to hardware.  Hardware
   is managed by the kernel so a process must use
   \textbf{system calls} to indirectly access hardware.  System
   calls are the fundamental interface between an application
   and the kernel.  }


