From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3cd3b8571c28b75f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-08-28 18:02:47 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!wn11feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc04.POSTED!not-for-mail Message-ID: <3F4EA616.30607@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: A Customer's Request For Open Source Software References: <3F44BC65.4020203@noplace.com><20030822005323.2ff66948.david@realityrift.com> <20030822020403.625ffbf5.david@realityrift.com> <3F4657AD.1040908@attbi.com> <3F4828D9.8050700@attbi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: sccrnsc04 1062118966 24.34.139.183 (Fri, 29 Aug 2003 01:02:46 GMT) NNTP-Posting-Date: Fri, 29 Aug 2003 01:02:46 GMT Organization: Comcast Online Date: Fri, 29 Aug 2003 01:02:46 GMT Xref: archiver1.google.com comp.lang.ada:41929 Date: 2003-08-29T01:02:46+00:00 List-Id: chris wrote: > What do you mean 'avoid the file system'? I've heard people say if vast > amounts of persistant ram storage become available file systems will be > given the boot. Is that what you meant? If so I can't see it. You > still have to know where things are and more importantly you need a > conceptual association with data. That's all a file system is really, a > way to name blocks of data (people won't be able to remember 100 64bit > addresses, even in hex). Everything else is just built on top of that > simple idea. The details may (will) change but it'll still be a file > system. (Just a really fast, abundant and abused* one). What was so wonderful about Multics? In part, that it wasn't built around a file system, it was built around virtual memory. I won't go into the gory details here--you can find the Organik book if you haven't read it. But the memory concept in Multics was that everything was made of segments, and a process had access to segments. (Of course, some of the things in those segments were links to other segments.) The point though, is that you don't open a file and read it record by record or line by line. You map a segment into your process and can address any bit in the segment at random. The operating system may have some of pages of the segments your process has access to resident in memory and others still on disk, but you (and your applications) don't care. Access to the data is not mediated by the OS or the file system once you link to the segment. (Of course, on Multics when you linked to a segment both mandatory (security) permission levels and discressional access permissions are checked, and if those permissions change, the link will be snapped and have to be re-established with a new set of access checks. But all that is implementation detail.) This was the paradox of Multics that most people never understood. The system could afford to have good security because compared to conventional OSes security checks--and all of the other overhead of accessing a file--only needed to be done maybe one-thousandth as often, if that. The rest of what you talk about has to do with naming of datasets. Multics had both character string versions of pointers and "packed" hardware pointers. The character strings corresponded to file names (and a directory hierarchy) on a conventional system, plus the ability to address multiple entry points in a segment, or address an individual bit. The packed pointers were used by hardware to actually find the data. And as I alluded to above, converting a pathname to a segment table entry is the one time that access rights have to be checked. If the access control list or security level for a segment changes, then all existing page table entries are invalidated, and have to be revalidated to access the segment again. Neat, simple, and secure. So yes, when I talk about memory-mapping of files and not avoiding any file systems that is exactly what I mean. And until you have worked with a system that supports it well, you don't know what you are missing. Just one other example. Multics of course had dynamic linking, but the form of dynamic linking was much different from what we think of today. During development, you never invoked a linker. You just had all of the the code segments of your program lying around, pointed at the main program--or some other entry point, and said run. If you got to a point in your program where you called a procedure you hadn't written yet? The operating system would tell you that a call had been made to a segment it couldn't find. You could then run emacs, write the code, compile it, then--and only then--tell the OS where to find the code. Your program would continue running from the point where it had stopped. Once you had a complete, debugged program, you often invoked the binder, and put all your pieces together in one segment. Of course, there were probably lots of pathnames that connected to the OS, or to other subsystems, etc., that you left unresolved in the bound version. -- Robert I. Eachus "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh