The LispOS Project: a position paper, part 2

[Peter.VanEynde]

On Tue, 3 Jun 1997, Dwight Hughes wrote:

> Some general comments:
> 
> The use of a Mach-type kernel would certainly be better for
> our purposes than using a monolithic kernel based Un*x --
> that much less to wade thru. What is the status of MkLinux?
Sorry? Why should a Mach-type kernel be better?
You can use kernel modules to add functionality to the "monolithic" Linux
kernel. You can even use kerneld to load them as they are needed, like I
do for the printer, floppy, parallel port, minix fs, msdos fs,etc. drivers
at the moment.

It is my humble opinion that the Linux source is as modular as the Mach
kernel, it's just the built kernel that is "monolithic". It's all in the
eye of the beholder...

> Is it reasonably stable yet? How about on x86 hardware?

Seems reasonably stable. It works on x86, PowerPC and recently HP-PA
machines. IRC OSF selected it as the "bare minimum" server they will use
in all future ports of Mach...

> I would also agree that as a hardware platform for a LispOS,
> the PowerPC would be much nicer to work with than the x86 
...

Problem: there is no native code generator for the PowerPC in CMUCL. But
there is for the HP-PA, the Sparc  and the Alpha (all now supported by
Linux). 

> As for the goal of "Lisp down to the metal" -- that will be
                      ^^^^^^^^^^^^^^^^^^^^^^
I've been reading (In the little free time I still have left) the paper on
the original Lisp machine. There you can see that the machine was
developed to be easy to program in Lisp... The PC isn't made to be easy to
program, it's made to be cheap. Just think of the dozens of registers in a
normal VGA card that are (officially) write-only... The interlocks between
the registers, the timing that is sometimes critical... IMHO "down to the
metal" will only work if 
a the metal is designed to be used by a LispOS.
b the metal is a minimal kernel, I think Linux will fit the bill. Like I
said before: just think that Linux is an abstraction layer.

I would like option a, but nobody would buy it :-(.

...
> 1) the tight integration of GC and virtual memory (both
> hardware and software aspects), giving the ability to allow
> each to control the other tightly and take maximum advantage
> of resources (for example, being able to constrain GC to
> only deal with in-memory pages whenever desired);

I was thinking of this. It _can_ be done with a minimal kernel module and
mmap. But I've got philosophical problems: if you want to collect the
garbage in memory, you need to know what memory is referenced by the
swapped out memory. And how can you know that without swapping it in, or
keeping an expensive "pointers from outer space" list? But I know only a
little about GC, so can someone enlighten me?

> 2) being able to dynamically create/destroy multiple 
> scheduling policies definable by the applications
> themselves, not predefined in the kernel. These are somewhat
> outside the range of adaptability of any "standard" OSs,
> probably for several more generations of these OSs. I
> know you don't disagree with any of this -- you just see it
> as a lower priority item than I do (or at least lower on your
> list of interests).
Already mostly done :-).

There is a "RT-Linux" project that runs above the normal kernel. It would 
be trivial to add extensions, or to add a call-interface...

> My primary -reservations- about jumping on the Lisp-to-the-metal
> wagon are 1) all the broken devices we will have to deal with
> (I very much want to make maximum use of others' suffering
> to create good device drivers, especially video drivers) and
Sigh. Very true.

> 2) having to develop a good GUI interface for LispOS, along with
> everything else, and create programs using it. Sure, we could
> create a pure server LispOS (and make Kelly very happy), but that
> is definitely not on my interest list (I would want the LispOS
> to have the capability, but not *just* that).

I would just like people to help the free-clim project and add ports...
I've been _running_ the first release, so it sort-of-works. It just needs 
programmers. Even bad ones can help... just look at me :-).

> Your point that our time would be better spent *not* recreating
> the Un*x software library is well taken.
As I said before, we don't need a revolution, we need slow infiltration.
If LispOS is easier to program in, runs on all conventional OS, and can
communicate with the other programs, then people will flock to it...

Groetjes, Peter

--
It's logic Jim, but not as we know it.
Look in keyservers for PGP key.
Version: 3.12
GS/CS/L/C d->? s+:++>+@ a-- C++(+++)>$ ULOS++>++++$ P+>++++ L+++>++++
E>++ W+(--) U++>+++ o>+ K? w--- O>+@ M-? V? PS++ PE(--) Y+ PGP+>++
t++>+++ 5++ X++>+++ R tv b+++>++++ DI++ D++@ G+>++ e++>++++ h!>+ r+ y+