Xref: utzoo comp.unix.wizards:18737 comp.sys.hp:3213 comp.lang.c:22953
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bbn!usc!venera.isi.edu!raveling
From: raveling@isi.edu (Paul Raveling)
Newsgroups: comp.unix.wizards,comp.sys.hp,comp.lang.c
Subject: Re: Job Control (a la csh/ksh) from within C
Message-ID: <10163@venera.isi.edu>
Date: 17 Oct 89 00:07:05 GMT
References: <11237@smoke.BRL.MIL> <1989Oct6.164830.5856@utzoo.uucp> <1719@zen.co.uk> <1989Oct3.153120.4750@utzoo.uucp> <320@sopwith.UUCP> <10041@venera.isi.edu>
Sender: news@venera.isi.edu
Reply-To: raveling@isi.edu (Paul Raveling)
Organization: USC Information Sciences Institute
Lines: 29

In article <11237@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> 
> >	P.S.:  It's easier to implement good process/job control
> >	if you slip a more capable kernel underneath Unix instead
> >	of building a kludge over it.
> 
> This is a false dichotomy.  The UNIX kernel can be reengineered to
> properly handle such things, and in fact it has been.

	My original comment was poorly qualified.  What I meant
	to suggest was actually replacing a Unix kernel with a
	different kernel plus a Unix kernel interface layered
	between the new kernel and existing Unix-based software.

	A limited example was EPOS, which didn't have a full Unix
	interface layer, but it did have enough of one to allow
	compiling & running the old V6 icheck program without
	source changes.  This was needed because one of the 3
	file systems that EPOS supported was the Unix (V6) file
	system.

	An intriguing idea would be multiple interface layers
	to support different dialects of Unix (Sys V, BSD, HP-UX,...)
	on a per-job or per-process basis.


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