Flux toolkit as LispOS base
Fri, 2 May 1997 16:33:47 -0500 (CDT)
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, much
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.