essick@uiucdcs.UUCP (05/26/83)
#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@rand-relay