From owner-freebsd-current Wed Jun 4 11:13:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA15963 for current-outgoing; Wed, 4 Jun 1997 11:13:08 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA15934; Wed, 4 Jun 1997 11:12:54 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA23097; Wed, 4 Jun 1997 11:11:00 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd023095; Wed Jun 4 18:10:59 1997 Message-ID: <3395AF81.4487EB71@whistle.com> Date: Wed, 04 Jun 1997 11:10:09 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: current@freebsd.org CC: dyson@freebsd.org Subject: rfork() man page wrong? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've checked the man page and the sources.. it appears to me that the following section of the man page is wrong.. john, if you are reading, can you check if this is what you understand? ------- RFMEM If set, the kernel will force sharing of the entire ad- dress space. The child will then inherit all the shared segments the parent process owns. Other segment types will be unaffected. Subsequent forks by the parent will then propagate the shared data and bss between children. The stack segment is always split. May be set only with RFPROC. -------- now, as I read it, the section "The child will then inherit all the shared segments the parent process owns. Other segment types will be unaffected." is wrong because in RFMEM case, the vmspace is simply referenced twice, once by each process. regardless of how what segments it is made up of. (in the vm code.) if (flags & RFMEM) { p2->p_vmspace = p1->p_vmspace; p1->p_vmspace->vm_refcnt++; } also: "The stack segment is always split." seems to also be wrong.. (or is the stack not in the vmspace?) though of course there is a separate kernel stack. julian