Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!v.wales@ucla-locus
From: v.wales%ucla-locus@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Mystery system call in BSD Unix
Message-ID: <16874@sri-arpa.UUCP>
Date: Wed, 22-Feb-84 16:49:21 EST
Article-I.D.: sri-arpa.16874
Posted: Wed Feb 22 16:49:21 1984
Date-Received: Fri, 2-Mar-84 08:16:30 EST
Lines: 25

From:            Rich Wales 

Scott --

In reply to your question:

	What is system call #66 (0x42) in 4.0BSD Unix?  I have a hacked
	4.0BSD binary I'm trying to run on USG Unix, and this system
	call causes a SIGSYS + core dump.

System call #66 is "vfork" (we have a 4.1BSD system, but I believe this
call was the same in 4.0BSD).

"vfork" is a special variant of "fork" in which the child shares the
parent's virtual memory space.  The idea was to avoid having to make a
copy of a large process in cases where the child was just going to do
an "exec" anyway.

A "vfork" may not be equivalent to a "fork" if the child changes the
values of variables, but since Berkeley's documentation specifically
urged people right from the beginning not to exploit this feature, you
are probably safe in simply changing the "vfork" to a "fork" (system
call #2).

-- Rich