The LispOS Project: a position paper, part 2
Scott L. Burson
Mon, 2 Jun 1997 23:42:02 -0700 (PDT)
From: "Dwight Hughes" <email@example.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
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'.