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.
• Ensemble, a clustering version of ISIS-like group protocols over mcast: fault-tolerant RPC layer with failover, some support for realtime guarantees even with node restarts, etc.
• Softway Inc. has an OpenNT Unix/Posix compatibility subsystem for NT: http:www.OpenNT.com
• Butler Lampson on security recommends some reading:
  • Ross Anderson's homepage
  • Simple Distributed Security Infrastructure (SDSI)
  • Simple public key infrastructure (SPKI)

Deep Ports

NCR "Top End" server:

• NT has good service management but lacks basic support for monitoring/restart
• "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

Oracle server:

• 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

Margo Seltzer

• Source inspection can provide quick confirmation of hypotheses ("The problem with physics research is you can't view the source" -- paraphrase)
• Demonstrably successful fixes to source are even better than measurably successful ones
• Who actually signs? (PI can't sign; University must sign.)
• Publishing: do you need approval to publish?
• Liability: if students violate license, University is liable!
• Export 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? etc.
• 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 little.
• 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)

Brian Bershad

• Sometimes the lack of source leads to good tools (Etch).
• But sometimes you just want source: documentation, examples, measurement/analysis
• Sometimes you want to improve on something NT does, or use an "undocumented" API in a novel way or to do some new task. ("derivative work") Often 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.

Performance

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 sign.