relevant parts below. If you are confident in your HW1 code, you can
build on top of it. However, if you wish you can start with a fresh
copy of the code and re-implement @func{thread_join}, which is the
-only part of project #1 required for this assignment. Your submission
-should define @code{THREAD_JOIN_IMPLEMENTED} in @file{constants.h}
-(@pxref{Conditional Compilation}).
+only part of project #1 required for this assignment.
Up to now, all of the code you have written for Pintos has been part
of the operating system kernel. This means, for example, that all the
* Using the File System::
* How User Programs Work::
* Virtual Memory Layout::
-* Global Requirements::
+* Grading Requirements::
* Problem 2-1 Argument Passing::
* Problem 2-2 System Calls::
* User Programs FAQ::
limited.
@item
-File data is allocated as a single extent, so that external
-fragmentation can become a serious problem as a file system is used over
-time.
+File data is allocated as a single extent, that is, data in a single
+file must occupy a contiguous range of sectors on disk. External
+fragmentation can therefore become a serious problem as a file system is
+used over time.
@item
No subdirectories.
However one important feature is included:
@itemize @bullet
+@item
Unix-like semantics for filesys_remove() are implemented.
That is, if a file is open when it is removed, its blocks
are not deallocated and it may still be accessed by the
be contiguous. In fact, it must not require that any of the pages be
contiguous.
-@node Global Requirements
-@section Global Requirements
+@node Grading Requirements
+@section Grading Requirements
For testing and grading purposes, we have some simple overall
requirements:
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.
+
+@item
+In the previous project, we required that you provided some specific
+function interfaces, because we tested your project by compiling our
+test code into it. For this project and all later projects, this is
+no longer necessary, because we will do all of our testing with user
+programs. You must make sure that the user program interface meets
+the specifications described in the assignments, but given that
+constraint you are free to restructure or rewrite kernel code however
+you wish.
@end itemize
@node Problem 2-1 Argument Passing
@item SYS_exec
@itemx pid_t exec (const char *@var{cmd_line})
Runs the executable whose name is given in @var{cmd_line}, passing any
-given arguments, and returns the new process's program id (pid). If
-there is an error loading this program, may return pid -1, which
-otherwise should not be a valid id number.
+given arguments, and returns the new process's program id (pid). Must
+return pid -1, which otherwise should not be a valid program id, if
+there is an error loading this program.
@item SYS_join
@itemx int join (pid_t @var{pid})
@itemx int write (int @var{fd}, const void *@var{buffer}, unsigned @var{size})
Write @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. Fd 1 writes to the console.
+not be written.
+
+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
+long as @var{size} is not bigger than a few hundred bytes. Otherwise,
+lines of text output by different processes may end up interleaved on
+the console, confusing both human readers and our grading scripts.
@item SYS_seek
@itemx void seek (int @var{fd}, unsigned @var{position})
We have provided you a user-level function for each system call in
@file{lib/user/syscall.c}. These provide a way for user processes to
-invoke each system call from a C program. Each of them calls an
-assembly language routine in @file{lib/user/syscall-stub.S}, which in
-turn invokes the system call interrupt and returns.
+invoke each system call from a C program. Each uses a little inline
+assembly code to invoke the system call and (if appropriate) returns the
+system call's return value.
When you're done with this part, and forevermore, Pintos should be
bulletproof. Nothing that a user program can do should ever cause the
Returns true if successful, false if USRC is invalid. */
static inline bool get_user (uint8_t *dst, const uint8_t *usrc) {
int eax;
- asm ("movl $1f, %%eax; movb %2, %%al; movb %%al, %0; 1:"
+ asm ("mov %%eax, offset 1f; mov %%al, %2; mov %0, %%al; 1:"
: "=m" (*dst), "=&a" (eax) : "m" (*usrc));
return eax != 0;
}
Returns true if successful, false if UDST is invalid. */
static inline bool put_user (uint8_t *udst, uint8_t byte) {
int eax;
- asm ("movl $1f, %%eax; movb %b2, %0; 1:"
+ asm ("mov %%eax, offset 1f; mov %0, %b2; 1:"
: "=m" (*udst), "=&a" (eax) : "r" (byte));
return eax != 0;
}
projects / pintos-anon / blobdiff