Aucbvax.2134 fa.works utzoo!duke!decvax!ucbvax!dlw@MIT-AI Mon Jul 6 15:09:18 1981 Storage Question Restated From: Daniel L. Weinreb Peter Deutsch is completely correct about the Lisp Machine. Local naming is done with virtual addresses, which are meaningful throughout a single Lisp Machine and only within that machine. Files are handled in the traditional way (like Unix, not like Multics): you read and write them in a stream- oriented way. A Lisp Machine file system can be local or remote, but in either case it acts the same way: the file system is completely divorced from the Lisp World. To edit a file you read it in, making a copy (in a different format) inside the Lisp World. While you are editing the file, it is represented in terms of Lisp data structure (a linked list of structures representing text lines, plus other stuff, as it happens). Users never really deal with the virtual addresses in a numeric way, of course. All permanent storage is in the file system; Lisp objects all vanish when the machine is "cold booted", and there is no attempt whatsoever to preserve the integruity of Lisp objects across various system failures. I am not saying that this is the way all systems should be (it probably isn't), but that's how the Lisp Machine works now. It solves a lot of problems (integruity, sharing, allocation, checkpointing) in ways that are narrow and restricted but well-understood and simple. And, by the way, capabilities are NOT just pointers. By "capability", most people mean a name for an object on which there is a strictly limited set of allowed operations, controlled by a set of access control rules that are very powerful and allow advanced access control structures such as protected subsystems. Lisp does NOT have this, and Hydra does, and that is one of the main things Hydra is about. I am told by people I respect that both the System 38 and the Honeywell NSA have botched the basic principles of how to do a capability system. I do not know the details; I'm just passing on rumors. I was one of the architects of the Amber operating system for the LLL S-1 computer, which also has capabilities, in its own way. I think we followed a lot of the basic principles well, but our capabilities are very different from Hydra's in the way they fit into the system. They do serve as the basic naming facility for the kernel interface, and they do have powerful access control facilities, allowing protected subsystems. Amber doesn't have garbage collection but we don't think this is an important problem. Basic memory management/file access in Amber is most similar to Multics. In Amber, you acquire a capability to a segment, and then you initiate the segment, which causes it to appear in your address space. (The S-1 is a large-scale computer being developed at Livermore Labs. Amber has been almost all designed, and lots of it has been coded and tested. Jeff Broughton was the inventor of the current capability scheme and is in charge of Amber development.) ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.