From owner-freebsd-hackers Fri Mar 20 12:11:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA14173 for freebsd-hackers-outgoing; Fri, 20 Mar 1998 12:11:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA14018 for ; Fri, 20 Mar 1998 12:11:30 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id PAA17394; Fri, 20 Mar 1998 15:11:29 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199803202011.PAA17394@dyson.iquest.net> Subject: Re: mremap? In-Reply-To: <199803201638.IAA29607@dingo.cdrom.com> from Mike Smith at "Mar 20, 98 08:38:29 am" To: mike@smith.net.au (Mike Smith) Date: Fri, 20 Mar 1998 15:11:29 -0500 (EST) Cc: perlsta@cs.sunyit.edu, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > ok, i'm not promising anything here, but if i implemented mremap(), would > > there be any interest in allowing it into -current? > > > > mremap just allows for moving and resizing mmap'd segments. > > You're more than welcome to give it a try. I had a look at the way > Linux does it, and frankly the layering violations were pretty shocking > (although there appears to be a great deal less sophistication in their > VM system). > > I couldn't see how to provide similar functionality with FreeBSD, but > if you're willing to get a little close to the way that memory mapping > works (check with David Greenman if you need advice here) you should be > able to pull it off. > I was planning on implementing mremap. I am not sure of the api, but it should be "easy" to implement with our current VM code. Think of map entries as being the address space "chunks", and objects as being the data repositorys. I want to foster others knowing how the code works, so now I don't want to do it :-). It would take me about 4Hrs to implement, and I want more people on the project to be able to do this stuff. The initial learning curve is long, but after that, there will be more people yet who know how the VM code works!!! :-). Think of it like this: First, remove the old map entries in the destination location. Perhaps saving them for undoing the effects of this operation upon failure (if needed by the API.) Next, grab the map entries in the source location, removing them, if the API requires such. Otherwise copy them. When "grabbing" the map entries, make sure that you trim them on both sides (trim the address space chunks (entries).) Put the old map entries into the new place in the map, making sure that the offsets are fixed up... When copying the map entries, it is important to make sure that the state of the destination entries is correct. You'll have to UTSL to see how to do that. This is little more complex than forking a process, but not brain surgery... Our VM code as inherited from Mach, is extremely flexible and really easy to work with. Take a look at the fork code (vmspace_fork) for a slightly not applicable example of moving address space entries (map entries) around. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message