LispOS directly on hardware or on Unix kernel?

[Martin Cracauer]

> 
> At 3:13 PM -0500 4/29/97, Martin Cracauer wrote:
> >The CPU interface and hardware drivers alone are reason enough. If you
> >don't like Unix sematics, you probably don't want to tangle with i386
> >and Adaptec 2940, not to speak of junk like Atapi CDROMs.
> >
> >The same applies for Video card drivers. I see no other change to get
> >these than to run the X11 server of XFree86.
> 
> Wouldn't it be possible to -- on the PC implementation of a Lisp OS, or
> indeed on any implementation for which Linux already exists -- define some
> sort of driver compatibility layer?  That way, one could use the XFree86
> video drivers and Linux hardware drivers without having to have the whole
> Unix bag o' crap in there.

For Xfree's video cards drivers that's impossible. There is no real
driver, the hardware control is spreaded all over the X server,
which in turn uses almost everything from the Unix kernel. That's the
reason each different Video card family has its own Unix binary and
this binary has hardcoded Unix-stuff in it.

Some FreeBSD folks feel that this needs to be reworked, creating a
real abstraction layer. Lossing some speed for some saveness and
modularity. But this havn't happen. I don't think another group
besides XFree will show up to tangle with all these vidao cards. Hence
my conclusion that I want to keep XFree.

For OS hardware drivers, this would be possible. But you'd need quite
some infrastructure to run FreeBSD or Linux drivers. I'm sure you will
have a hard time fighting unexpected problems like timing differences
between the two OSes.

As long as we can't get to the video cards, this point is mood anyway.

The only other solution is to define a new Lisp machine without a
graphics console and require another machine with a X11 server and use
the Lisp beat remote everytime except for simple configuration tasks.

> I guess you can put me in the camp that wants a new Lisp Machine.  I'd even
> buy one of those el-cheapo PCs at Damark to run it and do what hacking time
> permits on it.  But just another Lisp environment, this time running on
> Linux, won't hold my interest.  If I want a Lisp environment that uses the
> platform's window system and system services, why shouldn't I just run
> Macintosh Common Lisp?

1) The whole configuration of the system is done in Lisp
2) The whole GUI system is under control of your Lisp world
3) No pun intended, but the macintosh is the mother of
   misconfiguration and a lot of suboptimal memory and process
   management problems. A Unix-kernel based environment can be much
   more robust.
4) Maybe not a reason for you, but there are some Unix features I want
   to keep. User and group based permissions amoung them. Performance
   under heavy memory load is a FreeBSD thing I want to keep.
5) You get sources for everything.

Don't understand me wrong: I'm certainly not against a LispOS as pure
as possible, keeping people who feel like you in the game is reason
enough.

But I also follow FreeBSD development closly and I know how much
hassle this hardware business is. And how much hassle interactions
between the drivers and the rest of the OS are. NetBSD and FreeBSD
share some drivers and the number of problem when running the same
code under these rather close kernels is already more than I would
like to face.

And I know that these FreeBSD and Linux folks actually like to think
in memory regions and bits, being C programmers after all.  I can only
repeat my point that I can't imagine that a Lisp hacker who is after
the purest possible Lisp environment goes down to the hardware level
or implements a driver compatibilty layer.


Let me turn the question: What exactly would you do in a pure LispOS
that you can't in a system containing a Unix kernel and running a
multithreaded Lisp on it?

I will give you Lisp function for every documented system call or
variable and also for every undocumented one you feel the need for. I
will add whatever hooks are needed for your Lisp process to tell the
Unix kernel to treat things (memory region, files etc) specially.

I think the difference is just that you can't hold kernel data
structure in Lisp data structes so that changing the Lisp data
structure will reflect the system's state. You'll have to use a
function to change things everytime.

But even the symbolics wasn't *that* pure. 

For now, I think the number of kernel data structures that you will
use so often that you want a Lisp data structure for direct
manipulation is too rare. But I'm really interestedt in your
opinion. Let us discuss things that need a more direct Lisp
representation that a function equivalent to a system call. That's
what thsis mailing list is for.

Happy Lisping
	Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>
http://cracauer.cons.org
Fax +49 40 522 85 36