Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!apple!agate!darkstar!Sun.COM
From: gingell@Sun.COM (Rob Gingell)
Newsgroups: comp.os.research
Subject: Re: System Call Interception
Message-ID: <2403@darkstar.ucsc.edu>
Date: 7 Apr 90 23:21:35 GMT
Sender: usenet@darkstar.ucsc.edu
Organization: Sun Microsystems, Mountain View
Lines: 47
Approved: comp-os-research@jupiter.ucsc.edu


In article <2278@darkstar.ucsc.edu> mbj@spice.cs.cmu.edu (Michael Jones) writes:
>I'm interested in descriptions of past or current systems which provide a
>mechanism for programs to intercept system calls in user code.
>...
>For instance, I know that Tenex was one of the early systems to provide such
>a mechanism (via the TFORK jsys).  I know that it was used in part for
>Arpanet filesystem support, possibly in conjunction with the National
>Software Works project.  But the only literature I have which describes it
>is the Tops-20 Monitor Calls manual, which obviously says nothing about what
>it was used for and how such applications were structured.  
>...
>Any information on such systems would be greatly appreciated.

There an article about the TENEX usage of system call trapping (or JSYS
trapping in TENEX/TOPS-20 terms) in the January 1978 issue of IEEE Computer.
It describes the "Resource Sharing Executive" (RSEXEC) program that was
an attempt at building some distributed resource sharing through the
ARPAnet TENEX community.  It did this by trapping various JSYSs and then
performing translation or augmentation of the basic system operation in
order to present the picture of a global (to the ARPAnet) TENEX name space.

Under an RSEXEC environment, you could use an "augmented" file name syntax
that permitted you to reference the resources of another system, e.g.:

	@type [CASE-10]<RANDOM>FILE-OF-SOME-INTEREST.TXT

or:

	@copy [UTAH-10]<SYSTEM>INFORMATION.FILE [BBN-TENEX]LPT:

to print files across the country (and reference some venerable TENEX's :-).
I believe you could also configure pseudo-environments out of various
network resources, and RSEXEC administered the charade by, as always,
translating operations into operations for both the local and remote
system(s).

RSEXEC was in operation from (I guess) around 1974 until probably the
mid-to-late '70's.  JSYS trapping seems now to be used only for program
debugging and tracing.  More information on JSYS trapping is the
proceedings of the 1975 NCC, AFIPS Conference Volume 44.

SunOS contains an augmented ptrace() for doing system call trapping.
It's use is for program debugging and monitoring via the program "trace".

System V Release 4 has a comparable facility through the /proc file system
and is used to implement the program "truss".