Running Unix programs under LispOS

[Luca Pisati]

Mike McDonald wrote:
> 
> >Date: Fri, 2 May 1997 11:30:07 -0600
> >From: "P. Srinivas" <srini@cs.usask.ca>
> >To: CsO 3335 <colin.oliver@gecm.com>
> >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.
> >
> >srini
> >
> 
>   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),
World (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.

> It's
> 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
>   mikemac@engr.sgi.com

--
Luca Pisati		       Voice:	 (310) 577-0518
Nichimen Graphics	       Fax:	 (310) 577-0577
12555 W. Jefferson #285        EMail:    pisati@nichimen.com
Los Angeles, CA 90066          Web:      http://www.nichimen.com