UserLand & Kernel efforts: complementary, not opposite
Fri, 2 May 1997 13:43:22 +0200 (MET DST)
There are been lots of comments lately
about what underlying kernel to choose for the LispOS project,
and how Lisp can take over parts of the services.
Let's (re)state my position:
0) There are two different kinds projects being discussed:
the first one, say 'LispEnv, will try to provide Lisp interfaces
for all user-visible functionality, ASAP,
even though performance might not be great.
The second one, say 'LispOS, would be a Lispy implementation
of system layers, so as to achieve performance and consistency
in a Lisp system.
LispEnv for obvious expediency reasons,
should be implemented on top of an *already available* free OS.
This currently means *BSD and/or Linux, though the situation may evolve
(HURD has been named).
It is not essential to LispEnv to map Lisp-provided services back
to the underlying Unixish kernel.
It would be a nice hack, and Linux userfs and *BSD/HURD Mach servers
show that it is quite possible.
But beware the way it could spread the myth
that Lisp is a slow language with unreliable latency,
because we would have had to go through tons of filters
while using some non-realtime GC.
In any case, don't expect great performance from that.
An *essential* feature of LispEnv will be the ability
to run on top of an existing system, so that users can still use
their legacy software until LispEnv fully takes over.
A full take over involves the translation/rewrite of lots of
legacy software, which is unlikely until people are convinced,
which in turns requires that an efficient runnable system
be made available to them beforehand.
because LispEnv will have to communicate with programs on the
underlying platforms, scsh-style system interfaces are needed;
they are useful to build the LispEnv on top of them anyway.
A free*ix based LispEnv can make a pretty good cross-development
platform for LispOS. It can be made available much faster,
though it will be limited in many ways by the un*x braindamage below.
For various utility reasons, a Lispy kernel needs be built on
top of as little Cish braindamage as possible:
to achieve performance and consistency, clean semantics and robustness.
For instance, Markus Daniels wondered about how we could
provide reasonable system services without some kind of
real-time GC; yet, real-time GC is costly,
all the more if we have SMP and suches.
Thus, we'd need multiple GC spaces, thus generic GC algorithms,
thus modular/functorial programming, etc.
Things that only using a Lisp language as a meta-language can bring.
A Lispy kernel could very well be used as the basis for better
Unix emulators than a C kernel can ever be:
multiple address spaces are useful for Lisp, and having them,
it's not hard to add support for monolithic Cish black-box processes.
Using Lispy wrappers, you could then define
in a fine-grained way how services are provided to C programs,
arbitrarily filter accesses to combine security while allowing useful work,
simply provide accesses to services developed with the full power
of a real programming language.
By having smart C compilers taking advantage of the underlying system,
with both high-level code transformations when possible
and fine-grained low-level protection when not,
we could even boost the performance of C programs!
An *essential* feature of LispOS is the performance and reliability
it can bring with respect to system implementation,
which is required to convince people
to move to Lisp and high-level languages.
Else, they will continue to write low-level C stuff,
and we will continuously have to adapt our LispEnv
to talk to interface to more C braindamage.
In the same way as Unix-based software can be ported to
direct hardware access through Flux, improvements done for a purely Lispy
environment can benefit back to the unix-based LispEnv,
by adapting software to go through slow syscalls
instead of fast direct access.
BTW, debugging GC software on top of a free*ix is nicer than rebooting.
LispOS can make a pretty good underlying platform for LispEnv.
It will free LispEnv from Cish braindamage, though it may take
some time to implement.
== Fare' -- email@example.com -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
TUNES is a Useful, Not Expedient System