From kragen@dnaco.net Tue Sep 29 11:12:34 1998 Date: Tue, 29 Sep 1998 11:12:33 -0400 (EDT) From: Kragen Reply-To: Kragen To: shap@eros.cis.upenn.edu Subject: questions about EROS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: I have a couple of questions about the way stability is handled in EROS, and was handled in KeyKOS. First, one of the reasons Unix is so much stabler than Microsoft Windows is that its configuration is stored in files that are not written to by the software that is configured by them, simple text files you create with vi. Windows maintains its configuration as part of its persistent state, in the Registry; if the Registry is corrupted (and it often is) then the configuration is invalid and you have to fix it. EROS or KeyKOS would seem to encourage doing the same thing -- simply store configuration as long-lived items on the heap of a long-lived process. If you don't do this, you sort of lose the benefit of the one-level store, don't you? (On the subject of a one-level store: a young friend of mine has a programmable calculator. He wanted to know how to make things like matrices persistent across runs of a C program on his PC. When I told him about files, he was rather dismayed.) Second, one of the reasons Unix can scale up to jobs bigger than typing a document and printing it is that pointer bugs inside a particular process have effects confined to that process. Obviously this is necessary for things like wild pointer writes, but it's also helpful for memory leaks. It would seem that having processes that live for years would tend to make even small memory leaks rather significant. Having programs split up into many separate processes should help this quite a bit, I imagine -- particularly if some of the processes were not as long-lived as the whole program. But it would seem that buggy processes would eventually need to be restored to some kind of a 'ground' state. So you sort of lose the benefit of processes persisting across reboots, don't you -- except for processes with no memory leaks? Third, it would seem that the kernel's data structures would seem to be much more critical in EROS than in Linux or similar systems. If the kernel gets a bad pointer in one of its data structures, and manages to checkpoint before it crashes, your system will be unstable until you reinstall everything, won't it? It might even be so bad that you wouldn't even be able to restore from the checkpoint without crashing. (It would seem that the corruption of EROS's simpler data structures would also be easier to prevent, of course.) These are comparatively minor objections compared to the major ones that can be leveled against any Unix kernel: it's 750,000 lines of code running as root, it is impossible to make secure, etc. Kragen -- Kragen Sitaker A well designed system must take people into account. . . . It's hard to build a system that provides strong authentication on top of systems that can be penetrated by knowing someone's mother's maiden name. -- Schneier