Flux toolkit as LispOS base

Tim Pierce twpierce@mail.bsd.uchicago.edu
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.

   Olin Shivers
   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.