Flux toolkit as LispOS base
Fri, 02 May 97 17:49:00 PDT
I'm not sure that Flux/Fluke/Oskit is the right way to go here.
I'm much more inclined towards the Mach4/Utah Lites, OSF MkLinux or GNU
Hurd stuff for the
i) Mach is mature proven technology, and provides nearly all the
functionality one would need to implement LispOS on a micro kernel.
don't have to do too much extra work to get it to do the right
especially if we can work off the OSF code base.
Plus, the new wonderful adventurous stuff we are going to do is
going to be part of the new LispOS itself.
ii) Mach already works on more than one hardware architecture. What I
Dec Futurebus vs. Sun Mbus vs PC PCI bus, in addition to Pentium
vs. Sparc vs. Alpha.
iii) Utah Lites/MkLinux already provide a working Linux based Unix
environment that we can
jettison or absorb later.
BTW, MKLinux (which is my preference) supports PowerPC, Intel x86
and PA-RISC already.
It wouldn't take too much additional effort to support Alpha, Sparc
Don't get me wrong.. I think Flux/Oskit is a *very* cool piece of
technology, and were we
to be doing OS research, an appropriate thing to use. Just not for this
From: Tim Pierce[SMTP:email@example.com]
Sent: Friday, May 02, 1997 4:34 PM
Subject: Flux toolkit as LispOS base
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
developers, particularly people who have had personal experience
with Flux or similar toolkits and might be able to comment.
According to the Flux project's home page, a new (and ``somewhat
incompatible'') release of the toolkit is scheduled for mid-May.
In the meantime, the current release is unavailable, but if we
decide that there is an immediate need to start hacking, we may be
able to persuade Jay Lepreau to provide it.
I'm booting ML directly on the hardware as the OS. Your code meant
that I could instantly get up and going by linking the SML/NJ
runtime against OSKit and booting. I have a lot of research
directions to chase with the theme of the advanced-language OS,
and much further down the line we'll hopefully rip out a lot of
what we've used from OSKit. But OSKit gives me an instant platform
to start with.
I could have tried to tease apart Linux, and used it, but it would
have been a long, drawn-out mess. OSKit was perfect for my needs,
especially since it has a lot of support for porting user code
(like SML/NJ) to run on a raw machine (e.g., the stdlib and I/O
libs). The remote gdb support was also key, and your documentation
was very valuable.
Research Scientist, MIT
October 7, 1996
[Flux's] purpose is to provide, as a set of easily reusable modules,
of the infrastructure ``grunge'' that usually takes up a large
percentage of development time in any operating system or OS-related
project, and allow developers to concentrate their efforts on the
unique and interesting aspects of the new OS in question. The goal is
for someone to be able to take the OS toolkit and immediately have a
base on which they can start concentrating on ``real'' OS issues such
as scheduling, VM, IPC, file systems, security, or whatever, instead
of spending six months first writing boot loader code, startup code,
device drivers, kernel printf and malloc code, a kernel debugger, etc.
The intention of this toolkit is not to ``write the OS for you''; we
certainly want to leave the OS writing to the OS writer. The dividing
line between the ``OS'' and the ``OS toolkit,'' as we see it, is
basically the line between what OS writers want to write and what they
would otherwise have to write but don't really want to.