From owner-freebsd-current  Thu Sep 18 17:06:30 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA19646
          for current-outgoing; Thu, 18 Sep 1997 17:06:30 -0700 (PDT)
Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA19631;
          Thu, 18 Sep 1997 17:06:23 -0700 (PDT)
Received: (from karpen@localhost)
	by ocean.campus.luth.se (8.8.5/8.8.5) id CAA11932;
	Fri, 19 Sep 1997 02:12:33 +0200 (CEST)
From: Mikael Karpberg <karpen@ocean.campus.luth.se>
Message-Id: <199709190012.CAA11932@ocean.campus.luth.se>
Subject: Re: FYI: regarding our rfork(2)
In-Reply-To: <199709182235.RAA09701@dyson.iquest.net> from "John S. Dyson" at "Sep 18, 97 05:35:33 pm"
To: dyson@FreeBSD.ORG
Date: Fri, 19 Sep 1997 02:12:33 +0200 (CEST)
Cc: current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

According to John S. Dyson:
> I am going to be changing our rfork implementation in the following ways:
> 
> 	Rename RFMEM to RFSHMEM, implying that we are fully sharing memory.
> 	Also implying that we don't support RFMEM in the same way as other
> 	OSes might.  Add an additional argument to rfork(2) to support
> 	specifying a new stack address in the child.  This argument is
> 	meaningful only if RFSHMEM is specified.  This mod will eliminate
> 	some potential timing windows when the child is running with the
> 	parents stack.  It will also eliminate the need for certain
> 	"gymnastics" in code that uses rfork with RFSHMEM.
> 
> 	I'll be committing the changes tonight, so let me know if anyone
> 	has problems with the concept.

Sounds good, but I as always I have some nosy questions out of
personal interest only:

Is rfork() in any way portable enough to even consider keeping it happy
in porting software? Is it/should we try to keep it compatible with other
BSDs at least?

If so:
  Would be be hard to do a "real" RFMEM too? (Probably not instantly since
  it is wanted that things fall over from the lack of RFMEM if they are
  using it. But when they are fixed.)

  Will it be a problem for compilation if the new argument is not given,
  or will it be a "..." argument, or something?

Thanks for listening... :-)

  /Mikael