Please vote for your favorite t-shirt idea by tomorrow at midnight. We
don't have an explicit design as yet, but here are the conceptual ideas.
Vote be sending the number of the idea you want to vote for to cs161@fas
with the subject: t-shirt vote. Some of these aren't quite completely
formed, but if they get enough votes we'll try to flush them out
appropriately. I've just cut and pasted any suggestion we've gotten to
cs161@fas in the past few weeks. If you think your suggestion is
missing, let me know. Thanks!
Oh, also send some indication of how interested you are in actually
purchasing one of these shirts assuming they are priced as any custom
t-shirt bulk purchase would be (come on, they're cool...make good
pajamas if nothing else)...
-----
Idea 1:
-----
Front:
What's up?
How's life?
How's it going?
Getting out much?
Did you see that movie?
etc..
Back:
CS161.
The answer to all of life's questions.
-----
Idea 2:
-----
Something involving the phrase: "I can't handle CS 161... I think I'll
just die now..." and/or "I've realized that I spend more time in GDB
then in bed."
-----
Idea 3:
-----
A polo with some saying on it in monospaced font, such as
Computer Science 161:
The Few, The Prou
Panic: result == ENOSLEEP
(alternatively, ENOLIFE)
Maybe we could get our group names in the sleeves? That'd be cool.
-----
Idea 4:
-----
Some Matrix reference involving "I wish I had taken the _blue_ pill..."
-----
Idea 5:
-----
"Deserted Island"
text: "I survived CS 161" printed with the word "barely" handwritten and
inserted with a carat after the word "I".
picture: A person washing up on the shore of a deserted island (as
though
he were just in a shipwreck and barely made it to shore alive). On the
island is a person sitting on a beach chair in the shade of a palm tree,
sipping a drink. The first person is wearing a shirt that says "CS 161"
while the person lounging in the chair is wearing a shirt that says
"GOV"
-----
Idea 6:
-----
"Life as an OS"
Nice and simple. The shirt will have "Computer Science 161" and the
following snippet of code in as non-geeky a way as possible:
#define ONE_DAY (60 * 60 * 24)
int
cs161(void)
{
time_t now = time(NULL);
if (now > due_date - ONE_DAY && now < due_date)
return ENOSLEEP;
else if (now > due_date)
panic("I think I'll just die now...\n");
}
Other possible function names include doasst, doCS161, sys_doasst,
sys_cs161, etc. The code can be rewritten and stuff but you get the
basic
idea...
First, thanks to everyone for filling out these surveys.
Some people made some technical points (or asked questions) that I
wanted to respond to:
- debugging user-level programs. Several people mentioned that
they'd like to be able to do this. So would I. :(
The problem is that the debugger requires access to the target
program's memory. System/161 can't tell by itself how to read
memory from a particular user process; only the kernel knows what
processes are and only the VM system knows how to find the right
pages.
So doing it in the obvious way would require next year's students
to put in a bunch of extra time during assignment 2 and 3 to
implement and test/debug the support code for user debugging.
This doesn't seem like such a great idea.
However, one might be able to accomplish something useful by
taking advantage of the instruction tracing, using additional
simulators running in parallel, or something like that. If anyone
has any ideas (crazy/wild ideas are fine), mail me or the course
staff.
I have a crazy idea that I think might work, but it's fairly
gross, so I'd be interested in hearing any other ideas that might
be out there.
- debugging assembly language. This was one of the few things that
was actually better last year. Last year the assembler generated
line number information for .S files so gdb would show the
assembly source as you traced through it and stuff. When we
changed toolchains for this year, the feature went away, and by
the time I realized it had, it was too late to do anything about
it. I'm planning to look into this for next year.
Unfortunately, gdb's support for debugging assembler is pretty
weak in general and there's not a whole lot we can do about it.
- multithreaded debugging. One of you observed that it would be nice
to be able to look at other thread contexts when the system is
stopped in the debugger. I agree; I believe gdb even has some
limited support for this. Unfortunately, I don't think it can be
done without compiling a lot of knowledge about the thread system
and scheduler into gdb, which would sort of be problematic. But
I'll look into it.
- instruction logging. One person asked whether there's a way to log
kernel instructions without the load being overwhelming.
Unfortunately, there isn't really. A binary log format might cut
the log size down, but not very much, and at the cost of making it
much harder to work with. So I don't think I'm going to do that.
You *can* turn the logging on and off from inside the kernel, by
using the functions in <lamebus/ltrace.h> for manipulating the
System/161 trace settings. This helps a lot, but only in limited
circumstances. (I realize this facility was almost completely
undocumented this year. I'll try to do better next time.)
It occurred to me just now that one could pipe the trace output
through gzip. I'll look into that; the traces should compress
quite well.
- profiling. Nobody mentioned this, but it's been on my list for a
while. It would be nice to be able to run sys161 in some kind of
profiling mode, and then run gprof to get call graphs and
per-function timing statistics and stuff, without needing to
change the kernel. Would anyone find this useful? Is it worth
spending time to get it working for next year?
- speed. The impression I get is that while it would be nice if it
were faster, the speed of System/161 is not a huge concern. If
this impression is vastly incorrect, please say so.
- finally, to the person who wrote me a thank-you on the survey:
You're very welcome. :-)
--
- David A. Holland / dholland(a)eecs.harvard.edu
Hey guys,
I just wanted to give a plug for the Plugged In talk our illustrious TF
Mike Vernal is giving tonight. It'll be about network security. Please
come, there will be free food, and we wouldn't want Mike to feel unloved.
It's in MD 221, 7 PM.
Dave
