From owner-freebsd-current  Tue Apr 16 16:38:09 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id QAA18046
          for current-outgoing; Tue, 16 Apr 1996 16:38:09 -0700 (PDT)
Received: from xi.dorm.umd.edu (root@xi.dorm.umd.edu [129.2.152.45])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA18040
          for <current@freebsd.org>; Tue, 16 Apr 1996 16:38:06 -0700 (PDT)
Received: from localhost (smpatel@localhost [127.0.0.1]) by xi.dorm.umd.edu (8.7.5/8.6.12) with SMTP id TAA06929; Tue, 16 Apr 1996 19:37:56 -0400 (EDT)
Date: Tue, 16 Apr 1996 19:37:56 -0400 (EDT)
From: Sujal Patel <smpatel@umiacs.umd.edu>
X-Sender: smpatel@xi.dorm.umd.edu
To: Garrett Wollman <wollman@lcs.mit.edu>
cc: current@freebsd.org
Subject: Re: rfork() changes 
In-Reply-To: <9604161549.AA17258@halloran-eldar.lcs.mit.edu>
Message-ID: <Pine.NEB.3.92.960416193544.5890E-100000@xi.dorm.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Tue, 16 Apr 1996, Garrett Wollman wrote:

> I would have no problem with implementing vfork() in libc as a call
> for fork().  Then, we can redeclare vfork() as LIBCOMPAT in
> syscalls.master, using fork() as the function, and eliminate all the
> kernel cruft completely.

I think this would be the best way to go about it.  Looking over the
entire source tree, it doesn't look like anything will break if vfork()
is actually fork().  Also, we should declare vfork() as ``obsolete'' in
the man page.  At this point, there is no advantage at all to using the
vfork() syscall instead of fork().  Any dissent?


Sujal