Flux toolkit as LispOS base

[Martin Cracauer]

Dwight Hughes writes:
> Tim Pierce wrote:
> >[...] 
> > I spent some of last night reading several of the URLs that have
> > been sent to this list.  The Flux project seems especially
> > relevant to what we are doing here, and I think we may want to
> > reconsider using it as a possible base.
> > 
> > These items are of particular interest, since they directly
> > address concerns that have been raised here about the feasibility
> > of ``starting from scratch'', and the importance of using existing
> > components.  This strikes me as a very exciting potential start
> > for a low-level Lisp kernel.  I'd like to hear feedback from other
> [...]
 
> I very much agree -- there are actually two potential sources of
> Unixisms and crippling. The Linux/*BSD kernel is one but the other
> is CMUCL. No fault of theirs but it was written *for* such systems
> -- as a result it contains whatever compromises, workarounds, or
> low-level changes were necessary to get it to run decently on such
> kernels. In short, it is warped to fit a hostile environment.

Is this comment backup up by real observation?

I think that CMUCL in fact *minimized* its Unix dependencies and that
it does very much in Lisp and on the base of lower level abstractions
than normal Unix kernel/ C-library semantics.

For example, it organizes its memory by getting memory areas using
mmap. It manages allocation or individual portions itself. I doesn't
use malloc, it doesn't use sbrk. What CMUCL uses from the operating
system is not much more than direct access to what the MMU gives
you. It can't be easier to move this to plain hardware. Of course,
CMUCL has C portions, noticeable the low-level debugger and much of
its process control, making heavy use of Unix signals.

But what CMUCL uses from Unix signals are more or less direct
interfaces to the hardware, too.

I hope I'm not mistaken here, but my impression from this discussion
is that people who vote against Unix signals forget that the hardware
is quite rough, too. I can't imagine you want the underlying OS to
provide higher-level signaling mechanism, what we want to pull
abstraction levels into Lisp, no?

So, you will take these low-level signals (or hardware exceptions, for
that matter) from your Lisp world anyway, no matter if you are on a
Unix kernel, an OSkit kernel or directly on the hardware. 

The difference is just that you do more or less of the pre/post signal
processing stuff from Lisp, but if it is clear what you want you can
modify any kernel you have source for, too.

Please, *if* I'm mistaken, please post some examples where you think
that Unix signals make things worse than what the hardware
provides. I'm very interestedt.

> We must use care not to propagate this into the core of the LispOS.
> Starting with a mostly clean slate with the Flux OStoolkit should
> allow us to properly identify and correct most such problem spots.

> I'm not against using CMUCL, it is only that we should keep this in
> mind and not warp our environment to fit a tool that was warped to
> fit unix-style kernels.

What we have to do is to replace the alien calls CMUCL uses with our
new functionality. It's as simple as that: Just replace the alien
function *definition* with a Lisp *implementation*. It's a single line
of Lisp code. As long as we still load a C library (which interfaces
to the Unix kernel system calls), all the functions are loaded into
CMUCL, but a loaded alien symbol isn't used unless you have an alien
function definition.

Unless you implement everything in Lisp (booting Lisp directly on
hardware), you will probably keep a C library with OS service
calls. And even here, CMUCL's interface is well-suited to use C code
without an Unix around it. It calls alien functions by a fixed address
in the code, it doesn't rely on the OS to tell it at runtime.

Happy Lisping
	Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>
http://cracauer.cons.org
Fax +49 40 522 85 36