Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Mar 1998 17:38:01 -0500 (EST)
From:      "John S. Dyson" <toor@dyson.iquest.net>
To:        jlemon@americantv.com (Jonathan Lemon)
Cc:        toor@dyson.iquest.net, mike@smith.net.au, perlsta@cs.sunyit.edu, hackers@FreeBSD.ORG
Subject:   Re: mremap?
Message-ID:  <199803202238.RAA18127@dyson.iquest.net>
In-Reply-To: <19980320161611.64201@right.PCS> from Jonathan Lemon at "Mar 20, 98 04:16:11 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
> On Mar 03, 1998 at 03:11:29PM -0500, John S. Dyson wrote:
> > 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!!! :-).
> 
> I have something similar to this, but slightly different:
> 
> I want to be able to map part of an address space of one process
> into the address space of a different process, at a different location,
> resulting in shared memory between the processes.
> 
> (Why?  I wanted a "vm86" process, with 1MB mapped starting at address 0, 
> and the same region mapped into the "control" process, at a different
> location.)
> 
> EG:
> 	boolean_t
> 	vm_map_shared(smap, dmap, saddr, daddr, size)
> 		vm_map_t smap, dmap;
> 		vm_offset_t saddr, daddr;
> 		vm_size_t size;
> 
> Would this type of routine be useful?
> 
I suspect that it would be useful, given a "use."  I don't know enough
about exactly what the userland API would/should look like (re: security,
and features) to implement it "off the top of my head."

If there is a reasonable justification for a new system call or equiv,
I am all for it!!!

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?199803202238.RAA18127>