file systems and vm machines]

Luca Pisati
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
  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-
  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).