Running Unix programs under LispOS
Fri, 02 May 1997 15:44:58 -0700
Mike McDonald wrote:
> >Date: Fri, 2 May 1997 11:30:07 -0600
> >From: "P. Srinivas" <email@example.com>
> >To: CsO 3335 <firstname.lastname@example.org>
> >Subject: Re: Running Unix programs under LispOS
> >This is what I was also thinking. Instead of the horrible
> >monolithic Linux kernal, we are better of the Hurd along with
> >micro kernal.
> >Another note: People are suggesting that we start with linux
> >and slowly re-implement all the linux in LISP.
> >Unix coded in LISP will still be UNIX not a LISPOS.
> >We should try not to duplicate all the garbage of Unix. We should
> >start with small micro kernal or a nano-kernal (is there any such
> >thing?) and provide a very simple and powerful OS interface.
> I don't believe anyone was seriously suggesting that we reimplement
> Unix in Lisp. I certainly wasn't. The idea is to start doing useful
> work today on the part that don't need direct OS support. As more and
> more of the system is functional and there's a need, replace services
> provided by the Unix kernel with Lisp based ones. Not ones that
> provide identical interfaces but better ones in terms of what lisp
> wants. As an example, networking. We can start today by implementing a
> generic networking layer in lisp that works on top of the existing
> Unix socket/streams interface. Lisp apps would then be written to use
> and provide the generic networking services. Later, the reliance on
> the Unix networking code code be replaced by lisp based code that was
> more tightly coupled to the generic networking system, not just
> providing lisp based sockets. In fact, the stack portion of the
> generic networking system should be written so that multiple
> networking protocols can be supported on an equal basis. Each of those
> protocols should provide the same interface to the upper layers of the
> generic networking system. When we replace the virtual memory system
> of Unix, we're not going to substitute another VM system that does the
> same thing only written in lisp. No, we're going to provide better
> support for our lisp based needs.
> >Unix compatibility mode may come later, if needed.
> >Just some thoughts.
> I kind of see the timeline looking something like this:
> LispOS based upon Unix -> native LispOS w/o Unix -> native LispOS
> with other OS compatibility, including Unix
> I'd guess a lot of people would avoid the middle step, but it's
> necessary. But that can be limited to the die hard types. I believe we
> need the Unix environment inorder for us to bootstrap the LispOS.
I do not see any problem on this, from a LispM point of view.
Genera had several layers:
1. FEP EPROM microcode, to bootsrap the hardware and provide
a level where you could load a
2. FEP kernel, which loads in memory and provides support for
memory management and load a
3. Lisp world, which is the Lisp environment.
Level 2 and 3 had debuggers: FEP (Kernel), Cold Load (lower lisp),
Maybe I'm not exact in the details, but ...
The nice feature of such a layer was that Genera was easiliy
adaptable to different hardware and OSes.
On the MacIvory, the FEP level was a Macintosh extension (providing
RPC communication to the Mac), and evrything else was the same.
On the UX, the FEP level was some connection to Sun Unix, and so on.
> really nice to have things like editors, news readers, Email while
> writing things like editors, news readers, and Email. It also allows
> us to use more people's talents. Not everyone wants to hack the kernel
> code. (I know, it's hard to believe!) While the kernel types work on
> their thing, the apps types can work on their's. Then, when the kernel
> is ready, maybe there will be something to run on it.
> Mike McDonald
Luca Pisati Voice: (310) 577-0518
Nichimen Graphics Fax: (310) 577-0577
12555 W. Jefferson #285 EMail: email@example.com
Los Angeles, CA 90066 Web: http://www.nichimen.com