Any details on 'the Newcastle Connec - (nf)

[essick at uiucdcs.UUCP]

#R:n44a:-15300:uiucdcs:13700033:000:2496
uiucdcs!essick    May 25 22:42:00 1983

	We've got a pre-release copy here at Illinois (since my advisor
got his PhD from NewCastle and is there on sabbatical). The Dec. '82 issue
of Software Practice and Experience has an article on the NewCastle
Connection (also called "Unix United" aka "UU").
	The package is (1) transparent to the user, (2) involves
NO kernel changes, and (3) portable between different versions of
Unix. NewCastle is running PDP-11's; someone in Germany has it
on 68000's and we are working with Vaxen at Illinois.
	The code is implemented as a layer between the user program
and the Unix kernel.  It runs in user space.  To the kernel, it appears
to be a user program; the user program perceives it as the kernel.
	The overhead for local calls is a few extra subroutine calls.
Remote calls appear to be limited by the network device (Ethernet, 
ringnet).
	Nice touches about the package:  If a program doesn't plan
on using the remote access capabilities, it can be compiled without
the NewCastle code and doesn't have to pay any of the overhead.
UU users and non-UU users can run together on the same machine(s).
	The filesystems are arranged in a tree structure (suprise!)
like the normal filesystem. From the CS departments `A' machine,
I could access the password file on the `B' machine by the pathname
/../b/etc/passwd.  To get the same file on the EE `A' machine I
might try /../../ee/a/etc/passwd.  Your "root" is the root of the
local sytem when you start; it can be changed to remote machines
via the chroot() system call.  "Artist's Conception" of the hierachy:

	/ +----  ee/ +-----  a/     (normal Unix filesystem)
	  |          |
	  |          +-----  b/     (normal Unix filesystem)
	  |
	  +----  cs/ ------  a/     (normal Unix filesystem)
	             |
	             +-----  b/     (normal Unix filesystem)

	Things like user id's, group id's, signals, and other assorted
odd's and end's are mapped across systems appropriately. Each machine
can be under it's own administration since uid's are mapped (not merely
carried over).  Remote execution works.  It makes things like centralized
line printer spoolers really simple.
	For more information, the best place to start is the article
in Dec. '82 Software Practice and Experience.  I'll have more information
as to the availability and maybe even some hard statistics later this
summer.

-- Ray Essick, University of Illinois
   USENET:  {pur-ee, harpo, parsec, ihnp4}!uiucdcs!essick
   CSNET (and maybe arpa too):   essick.uiuc at rand-relay