Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxj!mhuxr!ulysses!allegra!mit-eddie!godot!harvard!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: ptrace & Re: Mark Williams csd
Message-ID: <318@rlgvax.UUCP>
Date: Tue, 1-Jan-85 23:01:16 EST
Article-I.D.: rlgvax.318
Posted: Tue Jan  1 23:01:16 1985
Date-Received: Thu, 3-Jan-85 03:46:05 EST
References: <344@rna.UUCP>, <14@axiom.UUCP> <4842@utzoo.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 18

> Actually, V8's "/proc" (a directory all of whose files actually refer to
> system processes; open the file and reads and writes act on that process'
> address space) seems like a much cleaner solution to the nasty
> efficiency problems of ptrace, and it too is compatible.

Well, *some* of the problems.  V8 is based on 4.1BSD, so it assumes you
have virtual memory available.  If, on a machine which doesn't support
virtual memory or partial loading of processes, process A is debugging
process B, and process A and process B don't both fit into main memory,
"/proc" and "ptrace" are both going to be horribly inefficient.  I don't
know how much V8's implementation of reads and writes on a process' address
space depends on the kernel supporting virtual memory.

I do agree that, if implementable, "/proc" is 1000% the right way to do
things.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy