Date: Sat, 16 Mar 1996 12:51:26 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dawes@rf900.physics.usyd.edu.au (David Dawes) Cc: dyson@FreeBSD.org, current@FreeBSD.org, mmead@Glock.COM Subject: Re: Try this vm_mmap.c -- please Message-ID: <199603161951.MAA17791@phaeton.artisoft.com> In-Reply-To: <199603160821.TAA09552@rf900.physics.usyd.edu.au> from "David Dawes" at Mar 16, 96 07:21:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603161951.MAA17791>