Minimum set of primitives?

[Kragen]

On Thu, 19 Mar 1998, Rodrigo Ventura wrote:
>         BTW, I liked the idea of banning the filesystem. It's sort of
> using the physical memory as a huge cache to lisp objects all residing
> in disk. Of course a much more complex package system (or namespace)
> must be created, to incorporate all flexibility current filesystems
> support.

I don't think that's really necessary.  All you need is a single kind
of obarray that maps atoms to objects; some of the objects can be
obarrays.  This gives you all the flexibility of the Unix filesystem,
and comsiderably more, as well, and you need to implement *some* kind
of obarray anyway, in order to be able to run any programs.

The use-physical-memory-as-a-huge-cache idea is quite common in
self-hosted Lisp systems.  It's called a `single-level store'.  KeyKOS
<URL:http://www.cis.upenn.edu/~KeyKOS/> also does this.

By the way, it is useful (especially with RAID systems, especially with
RAID4, and especially with the large read caches that are becoming
increasingly common) to make the mapping of virtual memory to disk
blocks rather dynamic.  This way, a particular piece of data may be
stored in more than one place on the disk, which allows for atomic
checkpointing -- first, write all the dirty pages, then, point the
'latest-checkpoint' pointer at the new checkpoing.  Also, this improves
disk performance by an order of magnitude.

Some things that mar the beautiful abstraction:
- nonvolatile media can be removed and moved to another machine.  It's
useful if they can be read on that other machine.  This means being
careful about cross-device links.  This is especially useful in the
case of floppy disks, Zip disks, Jaz drives, etc., but even ordinary
hard drives are important.
- garbage collection requires some care if it is to be efficient.
- nonvolatile media sometimes fail.  It is useful if one disk failing doesn't
make the data on the rest useless.  This is connected with the removability 
property.
- some applications require durability -- that is, once they receive and
acknowledge a piece of data, they're expected not to lose it, even if the
machine gets unplugged immediately.  The need for this is obviously
strongest in the case of business applications, but it's nice even for
personal-use applications.  This means that applications have to have
some control over when their data gets written to disk.

I'm not familiar with how historical Lisp systems or KeyKOS handled
these problems, but I suspect they are solved problems.  Perhaps my elders
here can point us at some documentation.

(Well, KeyKOS handles the last one by offering a 'journal page' system call,
which forces a page to be written to disk immediately.  Database servers can
force a write on the page containing their latest log entry after each time
they make a log entry.  I'm not clear on how a Lisp system could handle this.)

Kragen