Flux toolkit as LispOS base

[John Casu]

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
following reasons::

i)  Mach is mature proven technology, and provides nearly all the   
underlying
      functionality one would need to implement LispOS on a micro kernel.   
 We probably
      don't have to do too much extra work to get it to do the right   
things properly,
      especially if we can work off the OSF code base.

      Plus, the new wonderful adventurous stuff we are going to do is   
presumably
      going to be part of the new LispOS itself.

ii)  Mach already works on more than one hardware architecture.  What I   
mean is
      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   
and MIPS.

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   
project.


 ----------
From:  Tim Pierce[SMTP:twpierce@mail.bsd.uchicago.edu]
Sent:  Friday, May 02, 1997 4:34 PM
To:  lispos
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.

http://www.cs.utah.edu/projects/flux/oskit/testimonials.html

     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

http://www.cs.utah.edu/projects/flux/oskit/oskitdoc/node3.html#SECTION0021  
00000
000000000000

   [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.