The LispOS Project: a position paper, part 2

[Scott L. Burson]

   From: "Dwight Hughes" <dhughes@intellinet.com>
   Date: Tue, 3 Jun 1997 00:51:53 -0500

   Some general comments:

   The use of a Mach-type kernel would certainly be better for
   our purposes than using a monolithic kernel based Un*x --
   that much less to wade thru. What is the status of MkLinux?
   Is it reasonably stable yet?

Evidently so.  See `http://www.mklinux.apple.com/'.

   How about on x86 hardware?

I see no indication that MkLinux will be ported to the x86, but that's okay,
because the Hurd runs on the x86.

						  I don't have a
   PowerMac/clone and they are not something one just scrapes
   together out of some spare parts like, say, a i486 system.
   The $ entry point from that point of view is rather higher
   for a PowerMac/clone, and I think will be for many on this
   list.

Well, let's see, today in my local paper I see a 7100/80 (one of the first
Power Macs, no match for a new one speedwise but well beyond a 486) advertised
for $750 with no monitor.  The cheapest machine you can buy new that runs
MkLinux today appears to be the 7200, which starts at $1300 sans monitor and
keyboard.  Support for more models is on the way.

Are those prices really prohibitive?

   As for the goal of "Lisp down to the metal" -- that will be
   thoroughly nontrivial, but I think there are also some
   nontrivial advantages in it, even today and for a number
   of years to come. Some advantages *I* am interested in: 
   1) the tight integration of GC and virtual memory (both
   hardware and software aspects), giving the ability to allow
   each to control the other tightly and take maximum advantage
   of resources (for example, being able to constrain GC to
   only deal with in-memory pages whenever desired);

Well, there is some hope that the Hurd already permits this kind of thing.  If
it doesn't, we can probably get the Hurders to put it in for us, as it's
clearly consonant with their goals.

MkLinux is another matter -- we would probably have to hack it in ourselves.
However, I wouldn't expect that to be too hard -- it's just a matter of
providing an interface to existing kernel structures.  (Famous last words :-)

   2) being able to dynamically create/destroy multiple 
   scheduling policies definable by the applications
   themselves, not predefined in the kernel. These are somewhat
   outside the range of adaptability of any "standard" OSs,
   probably for several more generations of these OSs.

Again, if it's not in the Hurd already, we may well be able to get them to add
it.  See `http://www.gnu.ai.mit.edu/software/hurd/hurd-paper.html'.

-- Scott