Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!hplabs!sdcrdcf!trwrb!aero!venera.isi.edu!raveling
From: raveling@vaxa.isi.edu (Paul Raveling)
Newsgroups: comp.software-eng
Subject: Re: The development tools (was: Configuration Management)
Message-ID: <4894@venera.isi.edu>
Date: 26 Feb 88 21:10:24 GMT
References: <497@aimt.UUCP> <5257@well.UUCP> <2984@metavax.UUCP> <2673@ihlpe.ATT.COM> <644@aimt.UUCP>
Sender: daemon@venera.isi.edu
Reply-To: raveling@vaxa.isi.edu.UUCP (Paul Raveling)
Organization: USC-Information Sciences Institute
Lines: 71

In article <644@aimt.UUCP> breck@aimt.UUCP (Robert Breckinridge Beatie) writes:
>In article <2673@ihlpe.ATT.COM>, daryl@ihlpe.ATT.COM (Daryl Monge) writes:
>
>Yes, but then isn't it obvious?  Isn't the real power of UNIX in that it
>is an environment that encourages tool building?

	No.  It REQUIRES tool building because the operating system
	itself doesn't offer good solutions to large sets of problems.

>
>The only restriction that seems desireable is "LEAVE THE KERNEL ALONE!".

	Many of the problems with Unix can't be solved without
	a different kernel.  I favor a substantially different
	kernel with a Unix compatibility layer over it to accommodate
	existing applications.  I'd write new applications for
	the new kernel's native facilities.


	To pick a few examples:

	We need asynchronous i/o.  What we did in EPOS was to issue
	a request as a signal (NOT like a Unix signal) to a device
	driver process; the device driver then issued an answering
	signal at completion.  These signals included event
	data and were queued if the destination process wasn't
	ready for them.  Lurking behind this terse description
	are about half a dozen things the Unix kernel can't do.

	We need GOOD interprocess communication.  The only
	Unix mechanisms that are standard enough to have some
	hope to contribute are pipes and signals.  There's
	nothing which efficiently communicates a small set
	of paramaters, such as those in typical C function calls,
	between processes.  Unix signals don't queue event data,
	and pipes are slow -- our benchmarks show that either
	the setup overhead for pipe i/o or context switching
	is easily an order of magnitude slower than it should be.

	We need to share memory among processes in a multi-process
	application.  There's no way to do this and keep
	application software portable between Unixes with different
	extensions.

	We need a single i/o interface with mutually consistent functions.
	We really don't want to have to check stream status, call
	Xpending, etc. before knowing it's safe to call select.
	In fact, it can never be totally safe to use select with
	streams or X connections without a polling time interval;
	if a context switch and input completion intervene between
	the stream/X connection check and the select, the select
	can leave the calling process blocked.

	We need to spawn processes without creating another copy
	of the entire address space (as in fork) and without having
	to fetch the new process from a disk file (as in vfork).
	The first part is especially important, since much of our
	project's software is Lisp running in a 40-megabyte address
	space, and we don't have enough swap space for another
	copy of it.

	I haven't even mentioned the question of user interfaces,
	but the problems there are equally dismal.


	Give Me Liberty or Give Me Unix!


---------------------
Paul Raveling
Raveling@vaxa.isi.edu