file systems and vm machines]
Luca Pisati
pisati@nichimen.com
1 May 97 23:51:26 -0700
As far as I can see, the LispOS will face a fairly big logistical
issue in its development because it is so integrated.
The integration of a LispOS is its big strength, but it also makes it
hard to make fast progress.
For example, to implement the OO file system needs massive support
from the virtual machine and garbage collector. And just implementing
the storage mechanism, even a quick and dirty one to get started is a
lot of work too.
Yes, it is alot of work, but we could anyway take a Symbolics like
approach. Since that machine was pretty much made of layers,
each layer being a machine by itself (FEP -> Cold Load -> Lisp World),
the filesystem had a similar approach:
1. A low level file system (FEP) extremely simple and limited (unix like ?)
2. A hig level file system (LMFS, originally an hack created by some user),
implemented in partitions which were files of the lower level FS.
2 could be fully superceding 1 after a while.
All this has been done before (See the Gemstone commercial OODB for
example), but it a big project in itself.
But to get very far on the user-level apps you really need this in
place.
For example, part of the mail subsystem might be a list of users, each
with a hash-table of mail articles, and there might be a global hash
table of aliases. To get a mail article by subject you might go...
(mail-by-subject "*LispOS*" (users-mail "Chris Bitmead" (mail *root-
dir*)))
The code to send a piece of mail to all aliases might be...
(defun send-mail (mail address)
(map-car post-a-piece-of-mail
(map-car equal? (mail-aliases *root-dir*) address))
But to start implementing all these state-of-the-art LispOS style
apps, you need this OO file system in place.
I mean, to take an analogy .... How far would you get writing a UNIX
application if all you had was a raw-partition to work with, but no
file system?
That is what it will be like developing next-generation LispOS apps
with only a UNIX file system.
As the example above, you could start using Unix FS, building a proper
FS after, using unix files as partitions, then being able to use the
proper FS natively (which is what Symbolics never did, paying a
performance price).