Re: [COFF] [TUHS] man-page style

Sure. (Note that I'm not on COFF, so if anyone replies, please make sure I'm CC'd directly.) Basically, it boils down to 'monolithic OS's are bad' - for all the reasons laid out in the usual ukernel places (I first saw them in the BSTJ MERT paper, IIRC). {What follows is not the crispest way to explain it; sorry. I didn't feel like deleting it all and re-writing to get straight to the point, which is 'Multics had many of the advantages of a ukernel - and a long time before the ukernel idea arrived - but without the IPC overhead, which seems to be the biggest argument against ukernels'.} Now, early UNIX may have done pretty well in a _tiny_ amount of memory (I think our -11/40 V6 had about 64KB of main memory _total_, or some such ridiculous number), and to do that, maybe you have to go monolithic, but monolithic is pretty Procrustean. This was brought home to me in doing early TCP/IP work on PDP-11 Unix. The system was just not well suited to networking work - if what you wanted to do didn't fit into the UNIX model, you were screwed. Some people (e.g. BBN) did TCP as a process (after adding IPC; no IPC in UNIX, back then), but then you're talking a couple of process switches to do anything. I looked at how Dave Clark was doing it on Multics, and I was green with envy. He added, debugged and improved his code _on the running main campus system_, sharing the machine with dozens of real users! Try doing that on UNIX (although nowadays it's getting there, with loadable kernel stuff - but this was in the 70's)! To explain how this was even possible, you need to know a tiny bit about Multics. It was a 'single level store' system; process memory and files were not disjoint (as in UNIX), there were only segments (most of which were long-lived, and survived reboots); processes had huge address spaces (up to 2^18 segments), and if you needed to use one, you just mapped it into your address space, and off you went. So he wrote his code, and if I in my command process executed the 'TELNET' command, when it needed to open a TCP connection, it just mapped in his TCP code, and called TCP$open() (or whatever he named it). It fiddled around in the networking state (which was in a data segment that Dave had set up in his 'networking' process when it started up), and set things up. So it was kind of doing a subroutine call to code in another process. The security wasn't good, because Multics didn't have set-uid (so that only Dave's code would have had access to that state database) - when they later productized the code, they used Multics rings to make it secure. But still, that was pretty amazing. The key thing here is that nobody had to modify the Multics 'kernel' to support adding networking - the basic mechanisms (the single-level store, etc) were so powerful and general you could write entirely new basic things (like networking) and add them 'on the fly'. What Multics had was quite different from ukernels, but it amounted to the same thing; the system wasn't this monolithic blob, it was layered/modularized, and you could see (and gain access to, and in some cases replace - either just for yourself, or for everyone) the layers/modules. The nice thing was that to call up some subsystem to perform some service for you, you didn't have to do IPC and then a process switch - it was a _subroutine call_, in the CPU's hardware. I don't think anyone else ever tried to go down that path as a way to structure an operating system (in part because you need hardware support), and it's a pity. (UNIX, which would run on anything, killed just about _everything else_ off.) The 386-Pentium actually had support for many segments, but I gather they are in the process of deleting it in the latest machines because nobody's using it. Which is a pity, because when done correctly (which it was - Intel hired Paul Karger to architect it) it's just what you need for a truly secure system (which Multics also had) - but that's another long message. Noel