one process at a time, you must manage things correctly to maintain
this illusion.
+FIXME
Before we delve into the details of the new code that you'll be
working with, you should probably undo the test cases from project 1.
All you need to do is make sure the original
@menu
* Project 2 Code to Hack::
+* Using the File System::
* How User Programs Work::
* Global Requirements::
* Problem 2-1 Argument Passing::
* System Calls::
@end menu
-@node Project 2 Code to Hack, How User Programs Work, Project 2--User Programs, Project 2--User Programs
+@node Project 2 Code to Hack
@section Code to Hack
The easiest way to get an overview of the programming you will be
works.
@end table
-Elsewhere in the kernel, you will need to use some file system code.
-You will not actually write a file system until the end of the
-quarter, but since user programs need files to do anything
-interesting, we have provided a simple file system in the
-@file{filesys} directory. You will want to look over the
-@file{filesys.h} and @file{file.h} interfaces to understand how to use
-the file system. However, @strong{you should not modify the file
-system code for this project}. Proper use of the file system routines
-now will make life much easier for project 4, when you improve the
-file system implementation.
-
Finally, in @file{lib/kernel}, you might want to use
@file{bitmap.[ch]}. A bitmap is basically an array of bits, each of
which can be true or false. Bitmaps are typically used to keep track
@var{n} is in use, then bit @var{n} of the bitmap is true. You might
find it useful for tracking memory pages, for example.
-@node How User Programs Work, Global Requirements, Project 2 Code to Hack, Project 2--User Programs
+@node Using the File System
+@section Using the File System
+
+You will need to use some file system code for this project. First,
+user programs are loaded from the file system. Second, many of the
+system calls you must implement deal with the file system. However,
+the focus of this project is not on the file system code, so we have
+provided a simple file system in the @file{filesys} directory. You
+will want to look over the @file{filesys.h} and @file{file.h}
+interfaces to understand how to use the file system. @strong{You
+should not modify the file system code for this project}. Proper use
+of the file system routines now will make life much easier for project
+4, when you improve the file system implementation.
+
+You need to be able to create and format simulated disks. The
+@command{pintos} program provides this functionality with its
+@option{make-disk} command. From the @filesys{build} directory,
+execute @code{pintos make-disk fs.dsk 2}. This command creates a 2 MB
+simulated disk named @file{fs.dsk}. (It does not actually start
+Pintos.) Then format the disk by passing the @option{-f} option to
+Pintos on the kernel's command line: @code{pintos run -f}.
+
+You'll need a way to get files in and out of the simulated file
+system. The @code{pintos} @option{put} and @option{get} commands are
+designed for this. To copy @file{@var{file}} into the Pintos file
+system, use the command @file{pintos put @var{file}}. To copy it to
+the Pintos file system under the name @file{@var{newname}}, add the
+new name to the end of the command: @file{pintos put @var{file}
+@var{newname}}. The commands for copying files out of a VM are
+similar, but substitute @option{get} for @option{get}.
+
+Incidentally, these commands work by passing special options
+@option{-ci} and @option{-co} on the kernel's command line and copying
+to and from a special simulated disk named @file{scratch.dsk}. If
+you're very curious, you can look at the @command{pintos} program as
+well as @file{filesys/fsutil.c} to learn the implementation details,
+but it's really not relevant for this project.
+
+You can delete a file from the Pintos file system using the @option{-r
+@var{file}} kernel option, e.g.@: @code{pintos run -r @var{file}}.
+Also, @option{-ls} lists the files in the file system and @option{-p
+@var{file}} prints a file's contents to the display.
+
+@node How User Programs Work
@section How User Programs Work
Pintos can run normal C programs. In fact, it can run any program you
by Linux, Solaris, and many other Unix and Unix-like systems.
Therefore, you can use any compiler and linker that produce
80@var{x}86 ELF executables to produce programs for Pintos. We
-recommend using the tools we provide in the @file{test} directory. By
+recommend using the tools we provide in the @file{tests} directory. By
default, the @file{Makefile} in this directory will compile the test
programs we provide. You can edit the @file{Makefile} to compile your
own test programs as well.
-@node Global Requirements, Problem 2-1 Argument Passing, How User Programs Work, Project 2--User Programs
+One thing you should realize immediately is that, until you use the
+above operation to copy a test program to the emulated disk, Pintos
+will be unable to do very much useful work. You will also find that
+you won't be able to do interesting things until you copy a variety of
+programs to the disk. A useful technique is to create a clean
+reference disk and copy that over whenever you trash your
+@file{fs.dsk} beyond a useful state, which may happen occasionally
+while debugging.
+
+@node Global Requirements
@section Global Requirements
For testing and grading purposes, we have some simple requirements for
status whenever a process exits. Aside from this, it should print out
no other messages. You may understand all those debug messages, but
we won't, and it just clutters our ability to see the stuff we care
-about. Additionally, while it may be useful to hard-code which
-process will run at startup while debugging, before you submit your
-code you must make sure that it takes the start-up process name and
-arguments from the @samp{-ex} argument. The infrastructure for this
-is already there---you just need to make sure you enable it! For
-example, running @code{pintos -ex "testprogram 1 2 3 4"} will spawn
-@samp{testprogram 1 2 3 4} as the first process.
-
-@node Problem 2-1 Argument Passing, Problem 2-2 System Calls, Global Requirements, Project 2--User Programs
+about.
+
+Additionally, while it may be useful to hard-code which process will
+run at startup while debugging, before you submit your code you must
+make sure that it takes the start-up process name and arguments from
+the @samp{-ex} argument. For example, running @code{pintos run -ex
+"testprogram 1 2 3 4"} will spawn @samp{testprogram 1 2 3 4} as the
+first process.
+
+@node Problem 2-1 Argument Passing
@section Problem 2-1: Argument Passing
Currently, @code{thread_execute()} does not support passing arguments
tests. If the tests fail, so do you. Fortunately, this part
shouldn't be too hard.
-@node Problem 2-2 System Calls, User Programs FAQ, Problem 2-1 Argument Passing, Project 2--User Programs
+@node Problem 2-2 System Calls
@section Problem 2-2: System Calls
Implement the system call handler in @file{userprog/syscall.c} to
@xref{System Calls}, for more information on how syscalls work.
-@node User Programs FAQ, 80x86 Calling Convention, Problem 2-2 System Calls, Project 2--User Programs
+@node User Programs FAQ
@section FAQ
@enumerate 1
@item
@b{Is there a way I can disassemble user programs?}
-@c FIXME
-The @command{objdump} utility can disassemble entire user programs or
-object files. Invoke it as @code{objdump -d @var{file}}. You can
-also use @code{gdb}'s @command{disassemble} command to disassemble
-individual functions in object files compiled with debug information.
+The @command{i386-elf-objdump} utility can disassemble entire user
+programs or object files. Invoke it as @code{i386-elf-objdump -d
+@var{file}}. You can also use @code{i386-elf-gdb}'s
+@command{disassemble} command to disassemble individual functions in
+object files compiled with debug information.
@item
@b{Why can't I use many C include files in my Pintos programs?}
@b{What happens when two (or more) processes have a file open and one of
them removes it?}
-FIXME FIXME FIXME
-
You should copy the standard Unix semantics for files. That is, when
a file is removed an process which has a file descriptor for that file
may continue to do operations on that descriptor. This means that
@end enumerate
@end enumerate
-@node 80x86 Calling Convention, System Calls, User Programs FAQ, Project 2--User Programs
-@appendixsec 80@var{x}86 Calling Convention
+@node 80x86 Calling Convention
+@section 80@var{x}86 Calling Convention
What follows is a quick and dirty discussion of the 80@var{x}86
calling convention. Some of the basics should be familiar from CS
the stack pointer, you have a couple of jumps which probably wrecks
some of your caches. This is why inlining code can be much faster.
+@menu
+* Argument Passing to main::
+@end menu
+
@node Argument Passing to main
@subsection Argument Passing to @code{main()}
address space, in the page just below virtual address @code{PHYS_BASE}
(defined in @file{threads/mmu.h}).
-@node System Calls, , 80x86 Calling Convention, Project 2--User Programs
-@appendixsec System Calls
+@node System Calls
+@section System Calls
We have already been dealing with one way that the operating system
can regain control from a user program: interrupts from timers and I/O
projects / pintos-anon / blobdiff