Fri, 16 Oct 1998 16:36:14 -0400 (EDT)
On Fri, 16 Oct 1998, Ray Dillinger wrote:
> 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.
I think this is generally called a "microkernel". The exokernel is
just an extension of this idea to its logical extreme.
It is a good idea. Sockets may not be the best communications
mechanism, of course. Look up information on KeyKOS and PUMA (which
have interesting, innovative, and simple ways for processes on a
microkernel to communicate) and Mach, QNX, and AmigaOS (which are the
most popular microkernel OSes).
(I'm not an OS researcher! Don't take my recommendations with too much
> 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
PUMA had an interesting solution for this that worked well
inter-machine as well as intramachine.
The socket API has some limitations that make what you have described
hard to do in the general case.
<firstname.lastname@example.org> Kragen Sitaker <http://www.pobox.com/~kragen/>
A well designed system must take people into account. . . . It's hard to
build a system that provides strong authentication on top of systems that
can be penetrated by knowing someone's mother's maiden name. -- Schneier