From owner-freebsd-current Sat Mar 16 11:56:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA27252 for current-outgoing; Sat, 16 Mar 1996 11:56:15 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA27246 Sat, 16 Mar 1996 11:56:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA17791; Sat, 16 Mar 1996 12:51:26 -0700 From: Terry Lambert Message-Id: <199603161951.MAA17791@phaeton.artisoft.com> Subject: Re: Try this vm_mmap.c -- please To: dawes@rf900.physics.usyd.edu.au (David Dawes) Date: Sat, 16 Mar 1996 12:51:26 -0700 (MST) Cc: dyson@FreeBSD.org, current@FreeBSD.org, mmead@Glock.COM In-Reply-To: <199603160821.TAA09552@rf900.physics.usyd.edu.au> from "David Dawes" at Mar 16, 96 07:21:38 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > It works fine with XFree86 3.1.2D. We can add MAP_SHARED to our code. > I don't like the idea of the mmap region being inherited by a child though. > I agree that MAP_PRIVATE doesn't make much sense for devices. All memory objects in a parent are inherited by the child following a fork. This is just "the way things work". The child process must be a duplicate of the parent in all respects except proc structure itself to operate correctly. You are are probably confusing "fork" and "exec" because of my previous posting. I think that since a "vfork" is to be followed by an "exec", then you could dispense with full duplication of mappings not specifically necessary to perform the exec... of course, this means the shared libc pages have to be there, etc.. I have stayed away from discussing vfork so far because of the implied problems with the BSD MAP_INHERIT across the exec. > BTW, I can't see anywhere where MAP_INHERIT gets used. It doesn't, AFAIK. I would typically expect it to be used within a set of cooperating tasks which are different binaraies, and, when taken together, constitute a service engine. For instance, we could have used it to avoid reestablishing mappings for service engines and the lock management engines and directory services server and remote request engines in the NWU servers. As it was, we had to have a library routine that attached the shared memeory segment and was called by each engine on startupt to establish mappings for the shared context data area. It's a useful idea; it would have dropped about 4000 lines of code, overall, over all of the regions managed by the memory pool manager. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.