Use standard POSIX "ustar" format for the scratch disk.

[pintos-anon] / doc / userprog.texi

diff --git a/doc/userprog.texi b/doc/userprog.texi
index 3541540173dee33fd674a50783dfc716c9dd9e17..aaf75e2aead1b749589d786f55e7ef12555d592f 100644 (file)
--- a/doc/userprog.texi
+++ b/doc/userprog.texi
@@ -204,7 +204,7 @@ commands for copying files out of a VM are similar, but substitute
 @option{-g} for @option{-p}.
 
 Incidentally, these commands work by passing special commands
 @option{-g} for @option{-p}.
 
 Incidentally, these commands work by passing special commands

-@command{put} and @command{get} on the kernel's command line and copying
+@command{extract} and @command{append} on the kernel's command line and copying

 to and from a special simulated ``scratch'' disk.  If you're very
 curious, you can look at the @command{pintos} script as well as
 @file{filesys/fsutil.c} to learn the implementation details.
 to and from a special simulated ``scratch'' disk.  If you're very
 curious, you can look at the @command{pintos} script as well as
 @file{filesys/fsutil.c} to learn the implementation details.


@@ -406,7 +406,7 @@ The second method is to check only that a user
 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
 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).
 
 because it takes advantage of the processor's MMU, so it tends to be
 used in real kernels (including Linux).
 


@@ -443,7 +443,7 @@ put_user (uint8_t *udst, uint8_t byte)
 {
   int error_code;
   asm ("movl $1f, %0; movb %b2, %1; 1:"
 {
   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
   return error_code != -1;
 }
 @end verbatim


@@ -872,7 +872,7 @@ call handler just prints @samp{system call!} and terminates the program.
 Until then, you can use @func{hex_dump} to convince yourself that
 argument passing is implemented correctly (@pxref{Program Startup Details}).
 
 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
 
 The @command{objdump} (80@var{x}86) or @command{i386-elf-objdump}
 (SPARC) utility can disassemble entire user


@@ -1090,17 +1090,18 @@ pointers.
 
 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
 
 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.
 
 
 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}:
 
 right before the beginning of the user program, assuming
 @code{PHYS_BASE} is @t{0xc0000000}: