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

next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 03, 1998 at 05:38:01PM -0500, John S. Dyson wrote:
> > 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."

Oh, I've already have this running, and it's just for internal kernel
use at the moment (no userspace API).  What I was really asking was if
this might be useful to a wider audience, and if the semantics aren't
too seriously deranged.
--
Jonathan

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?19980320165353.04445>