Re: A Customer's Request For Open Source Software

["Robert I. Eachus" <rieachus@attbi.com>]

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