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 @file{threads/test.c} is
where the bulk of your work will be:
@table @file
-@item addrspace.c
-@itemx addrspace.h
-An address space keeps track of all the data necessary to execute a
-user program. Address space data is stored in @code{struct thread},
-but manipulated only by @file{addrspace.c}. Address spaces need to
-keep track of things like paging information for the process (so that
-it knows which memory the process is using). Address spaces also
-handle loading the program into memory and starting up the process's
-execution.
+@item process.c
+@itemx process.h
+Loads ELF binaries and starts processes.
+
+@item pagedir.c
+@itemx pagedir.h
+A simple manager for 80@var{x} page directories and page tables.
+Although you probably won't want to modify this code for this project,
+you may want to call some of its functions. In particular,
+@code{pagedir_get_page()} may be helpful for accessing user memory.
@item syscall.c
@itemx syscall.h
distinction between them, although the Intel processor manuals define
them slightly differently on 80@var{x}86.} These files handle
exceptions. Currently all exceptions simply print a message and
-terminate the process. @strong{You should not need to modify this
-file for project 2.}
+terminate the process. Some, but not all, solutions to project 2
+require modifying @code{page_fault()} in this file.
@item gdt.c
@itemx gdt.c
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.
+interfaces to understand how to use the file system, and especially
+its many limitations. @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
can't run programs using floating point operations, since it doesn't
include the necessary kernel functionality to save and restore the
processor's floating-point unit when switching threads. You can look
-in @file{test} directory for some examples.
+in @file{tests/userprog} directory for some examples.
Pintos loads ELF executables, where ELF is an executable format used
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{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.
+recommend using the tools we provide in the @file{tests/userprog}
+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.
One thing you should realize immediately is that, until you use the
above operation to copy a test program to the emulated disk, Pintos
@file{fs.dsk} beyond a useful state, which may happen occasionally
while debugging.
+@node Virtual Memory Layout
+@section Virtual Memory Layout
+
+Virtual memory in Pintos is divided into two regions: user virtual
+memory and kernel virtual memory. User virtual memory ranges from
+virtual address 0 up to @code{PHYS_BASE}, which is defined in
+@file{threads/mmu.h} and defaults to @t{0xc0000000} (3 GB). Kernel
+virtual memory occupies the rest of the virtual address space, from
+@code{PHYS_BASE} up to 4 GB.
+
+User virtual memory is per-process. Conceptually, each process is
+free to use the entire space of user virtual memory however it
+chooses. When the kernel switches from one process to another, it
+also switches user virtual address spaces by switching the processor's
+page directory base register (see @code{pagedir_activate() in
+@file{userprog/pagedir.c}}.
+
+Kernel virtual memory is global. It is always mapped the same way,
+regardless of what user process or kernel thread is running. In
+Pintos, kernel virtual memory is mapped one-to-one to physical
+memory. That is, virtual address @code{PHYS_ADDR} accesses physical
+address 0, virtual address @code{PHYS_ADDR} + @t{0x1234} access
+physical address @t{0x1234}, and so on up to the size of the machine's
+physical memory.
+
+User programs can only access user virtual memory. An attempt to
+access kernel virtual memory will cause a page fault, handled by
+@code{page_fault()} in @file{userprog/exception.c}, and the process
+will be terminated. Kernel threads can access both kernel virtual
+memory and, if a user process is running, the user virtual memory of
+the running process. However, even in the kernel, an attempt to
+access memory at a user virtual address that doesn't have a page
+mapped into it will cause a page fault.
+
@node Global Requirements
@section Global Requirements
For testing and grading purposes, we have some simple requirements for
your output. The kernel should print out the program's name and exit
-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.
+status whenever a process exits, e.g.@: @code{shell: exit(-1)}. 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
@node Problem 2-1 Argument Passing
@section Problem 2-1: Argument Passing
-Currently, @code{thread_execute()} does not support passing arguments
+Currently, @code{process_execute()} does not support passing arguments
to new processes. UNIX and other operating systems do allow passing
command line arguments to a program, which accesses them via the argc,
argv arguments to main. You must implement this functionality by
-extending @code{thread_execute()} so that instead of simply taking a
+extending @code{process_execute()} so that instead of simply taking a
program file name, it can take a program name with arguments as a
-single string. That is, @code{thread_execute("grep foo *.c")} should
+single string. That is, @code{process_execute("grep foo *.c")} should
be a legal call. @xref{80x86 Calling Convention}, for information on
exactly how this works.
recommend adding a single lock that controls access to the filesystem
code. You should acquire this lock before calling any functions in
the @file{filesys} directory, and release it afterward. Don't forget
-that @file{addrspace_load()} also accesses files. @strong{For now, we
+that @file{process_execute()} also accesses files. @strong{For now, we
recommend against modifying code in the @file{filesys} directory.}
We have provided you a function for each system call in
@b{What's the difference between @code{tid_t} and @code{pid_t}?}
A @code{tid_t} identifies a kernel thread, which may have a user
-process running in it (if created with @code{thread_execute()}) or not
+process running in it (if created with @code{process_execute()}) or not
(if created with @code{thread_create()}). It is a data type used only
in the kernel.
same process, or you can use a more complex mapping. It's up to you.
@item
-@b{I can't seem to figure out how to read from and write to
+@b{I can't seem to figure out how to read from and write to user
memory. What should I do?}
-Here are some pointers:
+The kernel must treat user memory delicately. The user can pass a
+null pointer or an invalid pointer (one that doesn't point to any
+memory at all), or a kernel pointer (above @code{PHYS_BASE}). All of
+these must be rejected without harm to the kernel or other running
+processes.
-FIXME
+There are at least two reasonable ways to access user memory. First,
+you can translate user addresses (below @code{PHYS_BASE}) into kernel
+addresses (above @code{PHYS_BASE}) using the functions in
+@file{pagedir.c}, and then access kernel memory. Second, you can
+dereference user pointers directly and handle page faults by
+terminating the process. In either case, you'll need to reject kernel
+pointers as a special case.
+
+If you choose to translate user addresses into kernel addresses,
+you'll want to look at @file{threads/mmu.h}, which has all kinds of
+useful functions for manipulating virtual addresses.
@item
@b{I'm also confused about reading from and writing to the stack. Can
you help?}
-FIXME: relevant?
-
@itemize @bullet
@item
Only non-@samp{char} values will have issues when writing them to
@item
Each character is 1 byte.
@end itemize
+
+@item
+@b{Why doesn't keyboard input work with @option{-nv}?}
+
+Serial input isn't implemented. Don't use @option{-nv} if you want to
+use the shell or otherwise type at the keyboard.
@end enumerate
@item Argument Passing FAQs
You may find the non-standard @code{hex_dump()} function, declared in
@file{<stdio.h>}, useful for debugging your argument passing code.
Here's what it would show in the above example, given that
-@code{PHYS_BASE} is @t{0xc0000000}, so that the dump starts at virtual
-address @t{0xbfffffcc}:
+@code{PHYS_BASE} is @t{0xc0000000}:
@example
- 00 00 00 00 04 00 00 00-d8 ff ff bf ed ff ff bf |................|
- f5 ff ff bf f8 ff ff bf-fc ff ff bf 00 00 00 00 |................|
- 00 2f 62 69 6e 2f 6c 73-00 2d 6c 00 2a 2e 68 00 |./bin/ls.-l.*.h.|
- 2a 2e 63 00 |*.c. |
+bfffffc0 00 00 00 00 | ....|
+bfffffd0 04 00 00 00 d8 ff ff bf-ed ff ff bf f5 ff ff bf |................|
+bfffffe0 f8 ff ff bf fc ff ff bf-00 00 00 00 00 2f 62 69 |............./bi|
+bffffff0 6e 2f 6c 73 00 2d 6c 00-2a 2e 68 00 2a 2e 63 00 |n/ls.-l.*.h.*.c.|
@end example
@node System Calls
In the 80@var{x}86 architecture, the @samp{int} instruction is the
most commonly used means for invoking system calls. This instruction
is handled in the same way as other software exceptions. In Pintos,
-user program invoke @samp{int $0x30} to make a system call. The
+user programs invoke @samp{int $0x30} to make a system call. The
system call number and any additional arguments are expected to be
pushed on the stack in the normal fashion before invoking the
interrupt.
projects / pintos-anon / blobdiff