Date: Sat, 21 Mar 1998 00:32:23 -0500 From: "Alfred Perlstein" <perlsta@cs.sunyit.edu> To: <hackers@FreeBSD.ORG> Subject: Re: mremap? Message-ID: <016f01bd548a$b9e8be60$0600a8c0@win95.local.sunyit.edu>
next in thread | raw e-mail | index | archive | help
wouldn't a simple resolution lie in just "locking" the kernel, unmapping the segment and seeing if it was possible to remap it according to the user's wishes then mmap it again the unlock the kernel? in SMP situations if the request for a remap fialed right after the unmap we could check if the user specified the "unmoveable flag" and then remap as/if nessesary. maybe this isn't the most effecient method.. but i makes sense to someone who hasn't even looked at the sources yet in regards to implementing this. i'm looking at your proposals for mremap() right after i send this. -Alfred >-----Original Message----- >From: John S. Dyson <toor@dyson.iquest.net> >To: Mike Smith <mike@smith.net.au> >Cc: perlsta@cs.sunyit.edu <perlsta@cs.sunyit.edu>; hackers@FreeBSD.ORG ><hackers@FreeBSD.ORG> >Date: Friday, March 20, 1998 11:13 AM >Subject: Re: mremap? > > >>> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?016f01bd548a$b9e8be60$0600a8c0>