Usenix NT workshop, Aug 11, 1997
Stuff to check out
- Lotus Research -
talked to Quinton Zondervan and Mark Day (latter was lead author
of "What synchronous groupware needs" paper in HotOS V: a
"generic" async notification protocol, in the same sense that
RSVP is a "generic" resource reservation protocol). They would
like Pilot browser code, etc.
a clustering version of ISIS-like group protocols over mcast:
RPC layer with failover, some support for realtime guarantees
even with node
- Softway Inc. has an OpenNT Unix/Posix compatibility subsystem for
- Butler Lampson on security recommends some reading:
NCR "Top End" server:
- NT has good service management but lacks basic support for
- "Unix's security model is too simplistic; NT's is too complex and
hard to code" -- better documentation is helping
- "File access, suid, etc. insufficient on NT": really means NT's
model is different enough to require re-architecting your
security, not just re-engineering
- PID's are reused and not "guaranteed" unique! Ugh.
- NT "shell" sucks; no job control, etc. Shell scripts got
converted to Perl
- No parent/child processes, job detach on failure, etc. Makes it
difficult for processes to control other processes that they spawn.
- Development/debugging tools (VC++) far superior to Unix
- Don't port your abstractions: C runtime lib, signals, My Own
Threads, etc. Use the NT native versions of these.
- Nice abstraction "I/O completion port" bundles queue of blocked
worker threads and queue of incoming async I/O completions.
- Fibers: lightweight threads, with stack-only variables; 10's of
instructions to switch.
Panel: Do you need source?
Todd Needham, MS
New NT source licenses: can exchange source with like licensees, can
exchange object code with "anyone". Derivative work distribution
requires MS intervention. Researchers retain IP rights to their work,
but require commercial (vs research) license to distribute them
- Source inspection can provide quick confirmation of hypotheses
("The problem with physics research is you can't view the source"
- Demonstrably successful fixes to source are even better than
measurably successful ones
- Who actually signs? (PI can't sign; University must
- Publishing: do you need approval to publish?
if students violate license, University is liable!
restrictions: foreign grad students can't join project?
Geoff Lowney, DEC Spike project (Alpha NT optimizer)
- Much Alpha NT tool work done without source (some reverse engineering),
because of company politics.
- Embedded relocation information has been helpful for
instrumenting, but relo info is going away!
- Dataflow analysis hard: which references are volatile (and so not
loop-invariant? which registers are "really" live on return?
- A few researchers write their own OS's, to investigate OS
structure; the rest confine their (small) changes to
well-understood pieces of the kernel. Maybe MS should provide a
"research build" or SDK for the microkernel for the latter
group. ("What are you going to do with 10M lines of source?")
Werner Vogels (research assoc. Cornell U)
- Managing the source base: Grep is hard. Tags tables help a
- Since there's no docs for NT internals, the code is the
docs. (find examples, understand weird behaviors, find
undocumented but useful API's,debugging)
- Sometimes the lack of source leads to good tools (Etch).
- But sometimes you just want source: documentation,
- Sometimes you want to improve on something NT does, or use an
"undocumented" API in a novel way or to do some new task.
API's undocumented because of designer bias as to which API's
people would care about.
- Alternatives to having source: call someone you know (at MS);
look in other OS's; etc.
- Why might you not want source: stifle creativity; golden
handcuffs and MS's rights to your results
- Wrong question: "Do you need source". Right one: "Do you need
information". Sometimes source isn't best way to get the info.
Endo & Seltzer: measuring Windows NT
- Interactive system --> user-perceived performance important.
- Users expect some things to be slow, but unexpected slowness bad.
- Strategy: Use NT's (fairly good) data collection mechanisms; keep
collected data in an in-memory ring buffer for "a short
time". If bad performance is observed, write out data.
- Problem: confirming hypotheses requires either reverse
engineering or source, but source license is too restrictive to