Hey,
I've been having a bit of trouble allowing for backspace in the shell,
and it's pretty annoying during testing, because if we make typos, we
can't backspace over it.
You can definitely implement backspace with lseek, but the problem is
that the console device doesn't support lseek (since it's a serial
device). Has anyone run into this problem and/or know a way around it?
I've thought about using dup2, but I'm not exactly sure how it would
work.
Thanks a lot,
Brian
When you're doing your performance analysis, you may find yourself
wishing you could run a profiler. (Or you may not, either, but
whatever.)
System/161 can actually collect kernel profiles for you without any
extra action on your part. That is, you don't have to recompile with
profiling support.
To collect a profile, use trace161 instead of sys161 (as always for
features that slow the simulator down) and use the -P option, perhaps
like this:
trace161 -P kernel 'p /sbin/poweroff'
This will leave a file in the current directory that you can feed to
gprof, like this:
gprof kernel gmon.out
Note that on ice the default version of gprof (in /usr/local/bin) is
broken, although the system one (in /usr/bin) seems to work, so you
actually need to do
/usr/bin/gprof kernel gmon.out
Because the profile timing is done internal to System/161, and the
sample rate is high, the times are considerably more accurate than
usual for profilers.
The profiling support in System/161 is completely undocumented, so
save this mail. :-(
--
- David A. Holland / dholland(a)eecs.harvard.edu
There seems to have been some confusion about this on assignment 1,
and rather than just refer everyone to K&R I'll try to explain it.
C declarations are read from right to left:
char *a;
means "a is a pointer to char".
Thus if you write
volatile struct thread *lock_holder;
as many people did, you're saying that lock_holder is a pointer to a
volatile struct thread. In the case of the lock, however, the
volatility of the thread structures is unimportant; what you're
concerned with is the value of the pointer. So what you probably meant
is this:
struct thread *volatile lock_holder;
which means that lock_holder is a volatile pointer to an (ordinary)
struct thread.
(The same syntax applies to "const".)
--
- David A. Holland / dholland(a)eecs.harvard.edu
hi cs161-ers:
this came up in my section and confused a few of us, so i thought that i
should just offer a clarification.
follow the fork() guidelines given in the cs161 man pages. these specify that
after a fork() the process file table are not shared, but file objects in the
parent process are. so, calls to lseek() by the child on a file descriptor
than was open in the parent will change the parents file descriptor as well.
if you feel like this causes races, it does. more advanced versions of unix
provide private read/write/lseek functions as well as options to fork to
disable some of the behavior described above.
hopefully this helps, good luck with asst2.
-gwa-
hello cs161-ers:
a hint for asstX: duplicating code is a Bad Idea (TM), for a variety of
reasons:
1) you may not understand the code well enough to know if it works in a new
context (i.e. the one that you are copying it into).
2) if you decide to change the implementation you have to start keeping
multiple locations in synch.
3) it frequently indicates bad interface design.
if you find yourself cutting and pasting large (more than 5 lines) of code
from one place to another in os161 it's time to step back and think about your
interfaces and program flow. there is almost always a way to simplify things
so that you don't have to recycle code.
good luck!
-gwa-
Hi,
It says in the assignment that we can compile the shell for the alpha, and
that the supplied makefile already does this. I've written the shell, and
I'd like to run a few quick tests, and I'm wondering how to run it (my
partner is doing fork/exec and it's not done yet, so I have to run it on
digital unix). Does anyone know how to do this?
Thanks,
Brian
=======================
Brian Greenberg
bgreenb(a)fas.harvard.edu
=======================
I'm not in a hurry to get the solution set - I don't need it for now.
I told Ellen to calm down as well.
I only emailed 'cause I was worried maybe you posted the wrong thing.
like a final exam or something.
Sorry for the disturbance. After I changed the extension (the extension
was tgz[1] changed to tgz), it appears to be the kernel for HW1. Again,
sorry.
>From: "Alexandra (Sasha) Fedorova" <fedorova(a)eecs.harvard.edu>
>Reply-To: cs161-list(a)fas.harvard.edu
>To: cs161-list(a)fas.harvard.edu
>Subject: [cs161-list] Assignment 1 solution set
>Date: Sat, 22 Feb 2003 14:45:55 -0500 (EST)
>
>The solution set for Assignment 1 has been released. It is posted in the
>"assignments" section of the course web site.
>
>-- Sasha
>_______________________________________________
>cs161-list mailing list
>cs161-list(a)fas.harvard.edu
>http://www.fas.harvard.edu/mailman/listinfo/cs161-list
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
Sasha,
could you please doublecheck what you have posted.
is that the right solution set?
did you post the right one?
It looks more like HW2 than HW1
>From: "Alexandra (Sasha) Fedorova" <fedorova(a)eecs.harvard.edu>
>Reply-To: cs161-list(a)fas.harvard.edu
>To: cs161-list(a)fas.harvard.edu
>Subject: [cs161-list] Assignment 1 solution set
>Date: Sat, 22 Feb 2003 14:45:55 -0500 (EST)
>
>The solution set for Assignment 1 has been released. It is posted in the
>"assignments" section of the course web site.
>
>-- Sasha
>_______________________________________________
>cs161-list mailing list
>cs161-list(a)fas.harvard.edu
>http://www.fas.harvard.edu/mailman/listinfo/cs161-list
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
