OS design...

[Ray Dillinger]

I've been reading about the exokernel.  It does seem like a good
idea, generally speaking.  But while I was reading it, I had a
different idea....

You should understand something here: I am not used to thinking
about OS design.  I'm still trying random ideas on and dropping
them at about a rate of three or four a week as I get more
knowledgeable about the issues involved.  I'm creative and
smart, but I'm a rank beginner at OS design, and I know it.  The
ideas I had last week, I now know why they won't work, and the
ideas I have this week may be headed for the same place.  I'm
just brainstorming here.  Now, with that said..... 

I like the "modular" approach and I think it could be extended
very effectively to runtime as well as buildtime, and cover
*EVERY* subsystem of the kernel except managing processes, 
memory, and sockets.  

I'm picturing each and every hardware driver and operating
system service as a standalone process -- not a library to link
against.  User processes would communicate with them using
sockets.  Higher-level services, such as window management,
could be standalone processes that communicate with lower-level
services such as screen management over sockets, etc.  This
could keep user code small and fairly simple, and allow the
kernel to drop code and processes related to any services that
aren't being used, at any time, which would keep the memory
footprint small. 

Suddenly, the kernel is not married to *ANY* assumptions about
the hardware, other than the availability of addressible memory.
If someone wants to make an embedded system with no screen or
keyboard, then those programs ("persistent drivers?")  just
don't get loaded. 

And, very importantly from our point of view, it would raise the 
API above the level of the calling stack and raw pointers into
code, making it so it really *didn't* matter what language you
programmed in.  Also, such a simple  kernel ought to be quite
easy to implement or port.

This would require several things:  

1) *VERY* efficient socket implementation -- as shared memory 
   space, with copying cut as far as possible.  Forwarding a 
   socket's input to another socket's output should be just a
   matter of copying two pointers and notifying the kernel that 
   the buffer has been allocated to a different process. Note, 
   different methods would be needed for inter-machine
   communications.

2) a standard "language" for communicating dynamically typed 
   objects via sockets, as well as raw bytes. 

3) a very efficient multitasking implementation -- probably 
   with all processes sharing a single address space and using 
   credential-based resource protection schemes. (which I don't 
   really know enough about yet to say whether that's feasible
   or effective). 



Other ideas?  Comments?  Rebuttals?

			Ray