Minimum set of primitives?

[Kragen]

On Fri, 20 Mar 1998, Chris Bitmead wrote:
> It seems to me off hand, that the kernel then, is that which
> implements the Scheme (or Lisp) language. 

Well, at least the primitive operations: car, cdr, aref, etc.  It
doesn't have to implement call/cc, define, read, print, etc.

> Sure, it will work
> differently to normal Scheme implementations, but the Scheme
> language doesn't give the user the ability to do nasty things
> like pointer arithmetic and other nasty stuff. From the users
> point of view, he will be merely using a Scheme implementation,
> albeit one that implements multiple threads and stuff.
> 
> The other big question that arises is whether and how to support
> non-Scheme programs. That is where the debate starts as to
> whether UNIX should run underneath LispOS in order to support C
> apps (and provide a bootstrap or base system to avoid writing
> device drivers).

See <http://www.pobox.com/~kragen/c-on-lisp.html>.  I doubt it's
anything original, but it explores the issues.

I do think that avoiding writing device drivers is a *major* issue.
Device drivers compose most of the Linux kernel, most of the
programming effort that went into Linux, and much of the usefulness of
any OS.

It would be nice if we could define a `Linux device driver abstraction
layer' that has a fairly-small set of primitives (kmalloc, kfree,
MOD_DEC_USE_COUNT, etc.) that lets another OS use Linux device
drivers.  Or, from another point of view, lets you replace most of the
upper layers of the Linux kernel.

I do not anticipate that this will be easy.  I suspect that it may
require throwing together a hacked C compiler that lets us redefine the
behaviors of individual objects flexibly.

Another thing I've thought about is grafting LispVM capabilities onto
the normal Linux kernel, similar to the way Apache has grafted a Perl
VM onto itself in the form of mod_perl.  It should be safe to run Lisp
code inside the kernel.

Random thoughts...

Kragen