Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Mar 1998 21:52:58 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        toor@dyson.iquest.net (John S. Dyson)
Cc:        jlemon@americantv.com, toor@dyson.iquest.net, mike@smith.net.au, perlsta@cs.sunyit.edu, hackers@FreeBSD.ORG
Subject:   Re: mremap?
Message-ID:  <199803212152.OAA06633@usr09.primenet.com>
In-Reply-To: <199803202238.RAA18127@dyson.iquest.net> from "John S. Dyson" at Mar 20, 98 05:38:01 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > (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!!!

I would expect that it would be useful for thunking work to a VM86
process that would then make BIOS calls based on the "work" you gave
it.

IMO, this would be most useful is the VM86 process was, in fact, a
kernel process, so that it could be crafted and executed in kernel
space priori to the system coming available, and used for things
like INT 13 reads, INT 10 mode settings for video cards, and so on.


My preferred mechanism for doing this would be to use a call through
procfs to establish the mapping.

Of course, I preferred using procfs to set attributes on one's self
instead of an rfork implementation (this is, in fact, how I implemented
the interprocess sharng of the per process descriptor table in UnixWare).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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?199803212152.OAA06633>