lecture 13 notes
authorKyle Spaans <kspaans@student.math.uwaterloo.ca>
Thu, 18 Jun 2009 20:07:44 +0000 (16:07 -0400)
committerKyle Spaans <kspaans@student.math.uwaterloo.ca>
Thu, 18 Jun 2009 20:07:44 +0000 (16:07 -0400)
lec13-0618.tex [new file with mode: 0644]

diff --git a/lec13-0618.tex b/lec13-0618.tex
new file mode 100644 (file)
index 0000000..448e8f9
--- /dev/null
@@ -0,0 +1,79 @@
+\documentclass{article}
+\usepackage{fullpage}
+\usepackage{amsmath}
+\author{Kyle Spaans}
+\date{June 18, 2009}
+\title{Operating Systems Lecture Notes}
+\begin{document}
+\maketitle 
+
+\section*{Lecture 13 -- Loading Programs into Address Spaces}
+First, some quick notes relevant to the assignment:
+\begin{itemize}
+\item The VFS abstracts common ``file'' (files are like arrays of bytes, sort
+      of like an address space) operations into a FS-independant interface.
+\item The UIO structure describes the read/write operation plus location,
+      length, etc and needs to be passed as a reference to \texttt{VOP\_read()}
+      or \texttt{VOP\_write()}. It is useful because it keeps track or how much
+      work yet remains to be done. This is useful if we need to transfer say
+      2000 bytes of data, but the device we are transfering to takes data in
+      100 bytes chunks. The UIO structure can be given a userspace or
+      kernelspace pointer, and do the transfer for us. This saves us some work
+      for A2 for the \texttt{write()} system call.
+\item For implementing \texttt{fork()}, notice that there is a
+      \texttt{as\_copy()} function that we can write, but should come in handy.
+      And recall that the new thread/process created by \texttt{fork()} will
+      never has been in usermode before, so we need to put it there by having
+      it run the \texttt{md\_forkentry()} function.
+
+\subsection*{\texttt{execv()}}
+When the new address space is initialized, remember that we only need to touch
+addresses in the rance \texttt{0x00000000} to \texttt{0x7FFFFFFF}. The
+information that will describe the new address space comes from an ELF
+(Executable, Linking Format) file. ELF files have a magic header (with magic
+ELF bytes) and then some meta data to describe symbols, sections, and segments
+that they contain and then ``images'' of those segments. The metadata will
+describe the size of the section or segment, it's properties, and where it can
+be found inside the file. The image can then be directly copied into the
+process' address space. This is what the functions in \texttt{loadelf.c} do.
+If a segment described in the ELF file is larger than the amount of data in
+the ELF file, then the rest of the segment (in memory) can be filled with null
+bytes. In \emph{OS161} we only care about the text and data segments. Note
+that the stack is not described, but it only needs to be worried about at
+run time, not compile or link time. Some tools for poking at elf files are
+\texttt{cs350-readelf}, \texttt{cs350-objdump}, \texttt{cs350-nm}.
+
+\subsection*{Segment-Program Relations}
+(The kernel doesn't care about this stuff!) Programs are made up code and
+variables. When compiled, these get divided into sections, and the sections
+are put into segments. There are sections for text, data, read-only data,
+uninitialized and initialized global variables. See the notes for an example
+of which variables a C program will be put in which sections. The space for
+global variables, since they can't go in the stack, are given space in the
+program's data segment. Alignment can be tricky, look at what
+\texttt{loadelf.c} does currently -- notice how variables in the ELF file
+are word-aligned.
+
+\subsection*{Argument Passing}
+It's not entirely necessary, so we should work on this last. The two
+parameters to \texttt{main(int argc, char **argv)} must be manually placed
+in the process' registers. The first is just a count, and is easy to do.
+The second is a pointer, but it can't be a pointer to kernel space, so the
+kernel will have to copy those strings into \emph{some part} of the user's
+address space. Where is up to us. We could find an unused part of the data
+segment, or enlarge the data segment (by performing the correct calls and
+modifying the address space structure) and place it there, or we can
+create a third ``argument'' segment. Or perhaps put the strings at the
+bottom of the stack. We need to copy the strings, then create an array of
+pointers to the strings, then set \texttt{argv} to point to the array. As
+long as doing any of this doesn't clobber existing data in the process'
+address space.
+
+\subsection*{Memory Related System Calls}
+Systems usually have system calls for allocating memory to a process,
+\texttt{brk()} (break) or some such. Malloc usually deals with this, and
+poritions out the large chunk of memory that it gets from the kernel to
+user programs who call \texttt{malloc()}. We don't have to worry about
+this. There can be calls for created shared memory areas between
+processes as well.
+\end{document}