projects 3 and 4, but it is not strictly required.
You might find it useful to go back and reread how to run the tests
-(@pxref{Testing}). In particular, the tests for project 2 and later
-projects will probably run faster if you use the qemu emulator, e.g.@:
-via @code{make check PINTOSOPTS='--qemu'}. The qemu emulator is
-available only on the Linux machines.
+(@pxref{Testing}).
@menu
* Project 2 Background::
Pintos, kernel virtual memory is mapped one-to-one to physical
memory, starting at @code{PHYS_BASE}. That is, virtual address
@code{PHYS_BASE} accesses physical
-address 0, virtual address @code{PHYS_BASE} + @t{0x1234} access
+address 0, virtual address @code{PHYS_BASE} + @t{0x1234} accesses
physical address @t{0x1234}, and so on up to the size of the machine's
physical memory.
access memory at an unmapped user virtual address
will cause a page fault.
-You must handle memory fragmentation gracefully, that is, a process that
-needs @var{N} pages of user virtual memory must not require those pages
-to be contiguous in physical memory (or, equivalently, in kernel virtual
-memory).
-
@menu
* Typical Memory Layout::
@end menu
pointer points below @code{PHYS_BASE}, then dereference it.
An invalid user pointer will cause a ``page fault'' that you can
handle by modifying the code for @func{page_fault} in
-@file{userprog/exception.cc}. This technique is normally faster
+@file{userprog/exception.c}. This technique is normally faster
because it takes advantage of the processor's MMU, so it tends to be
used in real kernels (including Linux).
{
int error_code;
asm ("movl $1f, %0; movb %b2, %1; 1:"
- : "=&a" (error_code), "=m" (*udst) : "r" (byte));
+ : "=&a" (error_code), "=m" (*udst) : "q" (byte));
return error_code != -1;
}
@end verbatim
on. That is, @code{process_execute("grep foo bar")} should run
@command{grep} passing two arguments @code{foo} and @code{bar}.
-Within a command line, multiple spaces are equivalent to a single space,
-so that @code{process_execute("grep foo bar")} is equivalent to our
-original example. You can impose a reasonable limit on the length of
-the command line arguments. For example, you could limit the arguments
-to those that will fit in a single page (4 kB). (There is an unrelated
-limit of 128 bytes on command-line arguments that the @command{pintos}
-utility can pass to the kernel.)
+Within a command line, multiple spaces are equivalent to a single
+space, so that @code{process_execute("grep @w{ }foo @w{ }@w{ }bar")}
+is equivalent to our original example. You can impose a reasonable
+limit on the length of the command line arguments. For example, you
+could limit the arguments to those that will fit in a single page (4
+kB). (There is an unrelated limit of 128 bytes on command-line
+arguments that the @command{pintos} utility can pass to the kernel.)
You can parse argument strings any way you like. If you're lost,
look at @func{strtok_r}, prototyped in @file{lib/string.h} and
given arguments, and returns the new process's program id (pid). Must
return pid -1, which otherwise should not be a valid pid, if
the program cannot load or run for any reason.
+Thus, the parent process cannot return from the @code{exec} until it
+knows whether the child process successfully loaded its executable.
+You must use appropriate synchronization to ensure this.
@end deftypefn
@deftypefn {System Call} int wait (pid_t @var{pid})
-Waits for process @var{pid} to die and returns the status it passed to
-@code{exit}. Returns -1 if @var{pid}
+If process @var{pid} is still alive, waits until it dies.
+Then, returns the status that @var{pid} passed to @code{exit},
+or -1 if @var{pid}
was terminated by the kernel (e.g.@: killed due to an exception). If
-@var{pid} is does not refer to a child of the
+@var{pid} does not refer to a child of the
calling thread, or if @code{wait} has already been successfully
called for the given @var{pid}, returns -1 immediately, without
waiting.
@deftypefn {System Call} bool create (const char *@var{file}, unsigned @var{initial_size})
Creates a new file called @var{file} initially @var{initial_size} bytes
in size. Returns true if successful, false otherwise.
+Creating a new file does not open it: opening the new file is a
+separate operation which would require a @code{open} system call.
@end deftypefn
@deftypefn {System Call} bool remove (const char *@var{file})
Deletes the file called @var{file}. Returns true if successful, false
otherwise.
+A file may be removed regardless of whether it is open or closed, and
+removing an open file does not close it. @xref{Removing an Open
+File}, for details.
@end deftypefn
@deftypefn {System Call} int open (const char *@var{file})
Each process has an independent set of file descriptors. File
descriptors are not inherited by child processes.
+
+When a single file is opened more than once, whether by a single
+process or different processes, each @code{open} returns a new file
+descriptor. Different file descriptors for a single file are closed
+independently in separate calls to @code{close} and they do not share
+a file position.
@end deftypefn
@deftypefn {System Call} int filesize (int @var{fd})
@var{buffer}. Returns the number of bytes actually read (0 at end of
file), or -1 if the file could not be read (due to a condition other
than end of file). Fd 0 reads from the keyboard using
-@func{kbd_getc}. (Keyboard input will not work if you pass the
-@option{-v} option to @command{pintos}.)
+@func{input_getc}.
@end deftypefn
@deftypefn {System Call} int write (int @var{fd}, const void *@var{buffer}, unsigned @var{size})
Writes @var{size} bytes from @var{buffer} to the open file @var{fd}.
-Returns the number of bytes actually written, or -1 if the file could
-not be written.
+Returns the number of bytes actually written, which may be less than
+@var{size} if some bytes could not be written.
Writing past end-of-file would normally extend the file, but file growth
is not implemented by the basic file system. The expected behavior is
to write as many bytes as possible up to end-of-file and return the
-actual number written, or -1 if no bytes could be written at all.
+actual number written, or 0 if no bytes could be written at all.
Fd 1 writes to the console. Your code to write to the console should
write all of @var{buffer} in one call to @func{putbuf}, at least as
Until then, you can use @func{hex_dump} to convince yourself that
argument passing is implemented correctly (@pxref{Program Startup Details}).
-@item How can I can disassemble user programs?
+@item How can I disassemble user programs?
The @command{objdump} (80@var{x}86) or @command{i386-elf-objdump}
(SPARC) utility can disassemble entire user
@code{pid_t}. By default, they're both @code{int}. You can make them
a one-to-one mapping, so that the same values in both identify the
same process, or you can use a more complex mapping. It's up to you.
-
-@item Keyboard input doesn't work.
-
-You are probably passing @option{-v} to @command{pintos}, but
-serial input isn't implemented. Don't use @option{-v} if you
-want to use the shell or otherwise need keyboard input.
@end table
@menu
You may modify the stack setup code to allocate more than one page of
stack space for each process. In the next project, you will implement a
better solution.
+
+@item What should happen if an @code{exec} fails midway through loading?
+
+@code{exec} should return -1 if the child process fails to load for
+any reason. This includes the case where the load fails part of the
+way through the process (e.g.@: where it runs out of memory in the
+@code{multi-oom} test). Therefore, the parent process cannot return
+from the @code{exec} system call until it is established whether the
+load was successful or not. The child must communicate this
+information to its parent using appropriate synchronization, such as a
+semaphore (@pxref{Semaphores}), to ensure that the information is
+communicated without race conditions.
@end table
@node 80x86 Calling Convention
Then, push the address of each string plus a null pointer sentinel, on
the stack, in right-to-left order. These are the elements of
-@code{argv}. The order ensure that @code{argv[0]} is at the lowest
-virtual address. Word-aligned accesses are faster than unaligned
-accesses, so for best performance round the stack pointer down to a
-multiple of 4 before the first push.
+@code{argv}. The null pointer sentinel ensures that @code{argv[argc]}
+is a null pointer, as required by the C standard. The order ensures
+that @code{argv[0]} is at the lowest virtual address. Word-aligned
+accesses are faster than unaligned accesses, so for best performance
+round the stack pointer down to a multiple of 4 before the first push.
Then, push @code{argv} (the address of @code{argv[0]}) and @code{argc},
in that order. Finally, push a fake ``return address'': although the
entry function will never return, its stack frame must have the same
structure as any other.
-The table below show the state of the stack and the relevant registers
+The table below shows the state of the stack and the relevant registers
right before the beginning of the user program, assuming
@code{PHYS_BASE} is @t{0xc0000000}:
projects / pintos-anon / blobdiff