Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!sdcsvax!darrell
From: darrell@sdcsvax.UUCP
Newsgroups: mod.os
Subject: Re: Who needs files?
Message-ID: <2856@sdcsvax.UCSD.EDU>
Date: Thu, 12-Mar-87 13:07:06 EST
Article-I.D.: sdcsvax.2856
Posted: Thu Mar 12 13:07:06 1987
Date-Received: Fri, 13-Mar-87 21:28:00 EST
Sender: darrell@sdcsvax.UCSD.EDU
Organization: The MITRE Corporation, Bedford MA
Lines: 24
Approved: mod-os@sdcsvax.uucp

In article <2850@sdcsvax.UCSD.EDU> bagwill@decuac.DEC.COM (Bob Bagwill) writes:
>  With large address spaces and virtual memory, who
>needs files?  Why not define all storage as extended memory structures
>that may be loaded as needed.

That's approximately the approach I'm taking with the OS I'm writing
for the 80386, which supports both segmentation and paging.  My project
is to build a prototype implementation of the proposed MIL-STD-1838a,
aka. CAISa (Common APSE (Ada Programmer Support Environment) Interface
Set, revision a.  This system doesn't really have a "file system;"
instead, it has an entity-relationship-attribute data base with
strongly-typed components.  I'm mapping the components directly to
386 segments in virtual memory, and letting the underlying paging
system move them back and forth between RAM and disk.  User programs
will access data in ways that are half-way between file access and
manipulating memory-resident data structures.  BTW, the whole thing
is being written in Ada.

There don't seem to be very many people out there doing anything with
the 386's ability to do demand paging.  I'd love to share experiences
and even code (my stuff is all public domain, and MITRE is good at
keeping proprietary data secure).

              -- Bob