First proposal: what should LispOS feel like?

[Martin Cracauer]

Mike McDonald writes:
> 
> >Date: Tue, 29 Apr 1997 21:06:58 +0200 (MEST)
> >From: Martin Cracauer <cracauer@cons.org>
> >To: lispos@math.gatech.edu
> >Subject: First proposal: what should LispOS feel like?
> >
> >I think we don't have enough agreement here what we want to beast to
> >look like.
> >
> >How should LispOS be different from FreeBSD/Linux/X11 or Windows?
> 
>   The theory is that the tightly coupling of the various OS services
> under a LispOS allows you to quickly and efficiently do things that
> are really though to do in the compartmented world of a traditional
> OS. 
>
> >How should LispOS be different from a decent Lisp development system
> >(say: Lispworks) running on a normal platform?
> 
>   The theory is that all of those OS services should be integrated
> into the lisp environment so that you can monitor, change, replace, or
> fix any piece in the system. You should, according to the theory,
> treat system services just like any other function.

OK, I think we need to specify the parts you want to access.

When using a Unix kernel, you'll get functions to access and
manipulate kernel data structures.

One step further is that you have these data structures in Lisp, so
that manipulating them directly reflects to the system's state. I'm
not sure the symbolics did this often, either.

For which functionality that is currently in the Unix kernel and not
in the userlevel Lisp would you need direct manipulation instead of
function calls.

Then, we have to look at these:
- How many of these can be pulled out of the kernel into userland?
- How many could be mirrored to the Lisp process and when manipulating
  them reflected back to the kernel?

I think we can go rather far with these tricks, while still keeping
the running FreeBSD or Linux kernel with some extensions.

> >I want my new Lisp machine to ask me in advance for some things that
> >can't be changed once the Lisp is running (done using commandline
> >parameters on stock systems) and optionally to save these for further
> >repeat.
> 
>   What things can't you change after you've booted and you're up and
> running? That's the whole point of a LispOS, everything is changable
> from the user environment!

Just in case the implementation has hardcoded limits of some sort,
such a stack sizes. If there aren't any, even better.

But don't be mislead by the fact that most implementation don't
already have commandline switches ;-)

> >OK, the system boots into whatever normal state is defined. A typical
> >picture might be:
> >- all network interfaces has been brought up, including routes.
> 
>   I want these inside my lisp world.

You want the whole networking framework in Lisp?

That's certainly doable, although a lot of work.

The Unix implementations of network interfaces and protocols are
hacked-in anyway, they are not part of the normal driver
structure. The hardware driver have a clean abstraction.

For my needs, I'm certainly satisfied to use the current TCP/IP stacks
and manipulate it using functions to call syscalls, though.

I'd say pulling the protocols into Lisp can be done by each user as he
wants and we don't need this to start.
 
> >- it prompts me for login on network ports (like Telnet does)
> >- it prompts me for login on the console
>   
>   I'd prefer to see a lisp login prompt, not a Unix one.

The difference is just a Lisp listener instead of a Unix shell. 

[...]
 
> >- A meaningful Window management capability that is integrated with
> >  Lisp's needs. The most important feature is to support fastest
> >  selection of a given tool. That equivalent Genera's 'select'
> >  key. There should be one keystroke to get to the Listener, to the
> >  editor. The Window manager should be written in the platforms' Lisp
> >  dialect and probably be running in the same world as the editor and
> >  the listener.
> 
>   I already have one of these. :-) I'll send you my .ctwrm file that
> gives me Select-E, Select-M, Select-N, Select-W, Select-D, Select-S,
> and Select-T. (Select-L is on my home machine.) I use Caps-Lock for
> the select key. Works great! 

No go. I use Capslock for backspace already :-]

>   But I agree with your point. :-)
> 
> 
> >And yes, I want several worlds. Maybe the whole stuff for my login
> >session should be *one* world (Listener, Editor, Window manager,
> >Browsers). But the background processes like HTTP servers should have
> >their own world that survives crashes of my login world and that
> >doesn't get messed up by manipulating my "front world" (nice term).
> 
>   Having several worlds running at the same time is a problem. Which
> one has the TCP/IP stack in it? (Better be only one.) I can understand
> the desire to have a stable, delivery world and a developement world
> running at the same time. I just don't know how to do it. It's like
> having two copies of the Unix kernal running in case I crash the user
> one.

Yeah. As soon as you pull services (like networking) from the kernel
into Lisp, you probably want this Lisp world to be the same you're
running you userlevel stuff in.

We have to clarify which kernel services to provide from Lisp.
 
> >I didn't made my mind up about OO file store yet.
> >
> >
> >Conclusions:
> >- I want different User IDs with different permissions on Object like
> >  memory areas, files and port, whatever and I want different processes
> >  to be run under different UserIDs
> 
>   Not me! I want access to everything on the system. I hate annoying
> machines that think they can protect me from myself. Their
> "protection" just gets in my way.

That's just running one world as root.

> >- Therefore I want both: Lisp threads inside a world. And several
> >  worlds running in parallel, for different users or several for one
> >  user. 
> 
>   I vision is of a single user machine. (What percentage of Unix
> machine do you think actually have more than one real user on them at
> any time? I'd bet it's much less than 10%. And Windows machines? Zero?)

I think our goals can be integrated.

My machine is running a Unix kernel and I use the kernel-provided
Networking. I can use several Lisp worlds accessing networks, no
problem. Manipulating the networking stuff can only be done by using
Unix syscalls from some Lisp api.

You have one world running as root. You interface your world to
the network hardware drivers and provide networking yourself. 

I don't think these goal go into each others way. I think one could
also run both solutions on the same machine. Each physikal network
interface can be used by the kernel or by the Lisp world, but not
both. You'll have to run two Ethernet (or whatever) cards with
seperate IP addresses, but otherwise you can just hack your Lisp
protocol stack as you like while you still can use kernel networking
at the same time.

Of course, there is currently no way to use a network hardware driver
from a userlevel process, but it isn't difficult. The whole BSD
networking stuff is not that complicated.

This is, BTW, another reason to prefer FreeBSD over Linux. The 4.4BSD
networking framework has an excellent description in Richard
W. Stevens "TCP/IP Illustrated", while the Linux folks constantly
reimplement the whole networking.

Martin 
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
  cracauer@wavehh.hanse.de (batched, preferred for large mails)
  Tel.: (daytime) +4940 41478712 Fax.: (daytime) +4940 41478715
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
  Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany