Can someone help me/us out with the distinction between thread_exit and
thread_destroy? I know there are certain things you don't want to be doing
while the thread is running and you reserve those for thread_destroy, but is
there any other distinction? For instance, would you not want to call
thread_exit in kill_curthread because you don't trust the stack when you're
calling kill_curthread?
I'm trying to figure out where thread cleanup routines should go...
Nick
... though the fix probably won't help with any weird problems you
might be having.
Thanks to Nicholas Murphy for finding it.
Please apply this patch:
Index: src/kern/lib/bitmap.c
===================================================================
RCS file: /disk/disk0/cs161/CVSREPO/os161/src/kern/lib/bitmap.c,v
retrieving revision 1.3
diff -u -r1.3 bitmap.c
--- bitmap.c 2001/02/02 10:12:50 1.3
+++ bitmap.c 2001/03/08 02:55:57
@@ -41,6 +41,7 @@
if (b==NULL || v==NULL) {
panic("bitmap_create: Out of memory\n");
}
+ bzero(v, words*sizeof(WORD_TYPE));
b->v = v;
b->nbits = nbits;
return b;
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
hey,
does anyone know what should happen if one process opens a file, then another
process opens the file and writes onto the end of it, and then the first
process does an lseek with SEEK_END? specifically, what i'm wondering is
whether the first process sees the EOF as where it was when the first process
opened the file, or where it was after the second process wrote to the file.
brady
Since the header files are in different places in Unix than in OS161, what's
the best way to go about compiling the shell first on ICE and then for OS161
without having to go in and manually edit the code (or is that the best
way)?
Thanks,
Nick
Does anyone have an idea about how to address into userspace from kernel space
and vice versa? I understand this is a decent part of execv, but we are hitting
a wall here and have yet to figure it out after spending the weekend thinking
about it. Is there a set of functions/files that we should be looking at it (yes
this is pretty much a pathetic plea for help).
--arvin
There have been a lot of questions about errno, so I'll try to preempt any
more with this post.
Generally, the question that has been asked is, "How do I set the errno?"
The answer is, "You don't."
If mips_syscall() returns an error to mips_trap(), mips_trap()
sets the trapframe return value (v0) to the error, instead of the retval
it passed to mips_syscall(). Additionally, it sets a flag in a3 (which is
cleared when mips_syscall() returns successfully). This gets mangled
during the return back into usermode to setting the return value to -1,
and errno to the error value (yep, the same one you returned from
mips_syscall()).
This is why all the user interface to all syscalls defines that on
failure -1 is returned. This does *not* mean you return -1 from
mips_syscall(); mips_syscall() should return the actual error that occured
(eg. EINVAL).
I hope this serves as clarification and not confusion.
-amos
maybe this is a little late to ask, but could someone explain exactly why you
would want to declare anything in the locks volatile?
i had the impression that declaring something volatile told the compiler not to
optimize it away, but i don't see how that would be used except:
volatie int j;
for( j=0; j< 100000; j++); /* kill some time */
which shows up somewhere in the test code.
thanks for any thoughts,
brady
> From: David Holland <dholland(a)eecs.harvard.edu>
> Date: Fri, 2 Mar 2001 18:05:09 -0500 (EST)
> Subject: [cs161-list] volatile
>
> In C, the declaration syntax goes from right to left. So if you write
>
> volatile struct thread *foo;
>
> you have declared foo to be a pointer to (a struct thread which is
> volatile).
> [...]
> Many of you will want to change your lock implementations accordingly.
> [...]
An unending stream of 'Unknown syscall -1' messages is most likely
caused by letting your _exit syscall return. As noted in the
assignment, _exit is not supposed to return.
For those interested in more detail, here's the mechanism by which
this happens (and how it ends up being syscall -1 instead of a real
system call number):
First, gcc knows more than is really healthy for it about common Unix
functions. In particular, it knows *without being told by unistd.h*
that _exit() doesn't return.
Second, gcc optimizes based on this knowledge: after a call to _exit,
it skips stuff like stack cleanup and function return. So if _exit
returns, execution drops off the end of the function that called _exit
and we start executing whatever function happens to come next in the
program.
It so happens for our system that this function is often __syscall,
the piece of assembly language that actually makes a system call. Now,
if you have looked at this code (it's in src/lib/libc/syscalls-mips.S)
you'll see that it doesn't expect to be invoked directly. It expects
to be jumped to after the v0 register has been loaded with the number
of the system call to make. However, when we reach this code by
falling off the end of exit(), the v0 register has not had a real
system call number loaded into it. Instead, it has the return value
from the last function call, the call to _exit. Since _exit presumably
failed, or it wouldn't have returned, this is -1. The __syscall code
then does what it's been told and tries to make system call -1.
This, of course, fails, so we load -1 into the v0 register again.
Then we try to return from __syscall. This is what gets us into a
loop: the return address register still contains the address in exit()
from the original call to _exit(), so when we "return", we teleport
back there. Then we fall through into __syscall again and tries to
make system call -1 again, and so on ad infinitum.
It's a little subtle, but you should be able to follow through the
above looking at a disassembly of the OS/161 "false" program.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
Hi folks,
I might well be missing something here, but how do we go about compiling
the shell? Someone told me that this is done by running make from the
cs161/src/bin directory, but doing this gives me an error about the path
to unistd.h (for true.c) not being found.
Can somebody give me the right command(s) to compile the bin user
programs?
Thanks,
Ben
