Date: Fri, 20 Sep 1996 15:02:59 -0700 (PDT) From: Jonathan Mini <j_mini@efn.org> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: sos@freebsd.org, pialkin@abel.pdmi.ras.ru, msmith@atrad.adelaide.edu.au, emulation@freebsd.org Subject: Re: New doscmd available for testing/munching Message-ID: <Pine.SUN.3.91.960920150137.11965A-100000@garcia.efn.org> In-Reply-To: <199609201011.TAA14497@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Sep 1996, Michael Smith wrote:
> My 'conceptual model' for this went something like :
>
> - allocate 128K in the emulation process for screen memory.
> - when vt is activated, copy the area that falls under the physical screen
> memory to a temporary store.
> - mmap the screen memory onto your emulation's buffer.
> - copy your temporary store back.
> - when vt is deactivated, reverse the process.
>
> ... but I really don't know what happens when you mmap() screen memory
> onto a section of your process' space that is already mapped. Or would
> you swap between a mapping to screen memory and a file? Or could you
> map to _both_ screen memory and a file...?
Well, only two things can happen : either you get an error from the
kernel, or it "overwrites" the other mmap... you loose the previous mmap.
The kernel shouldn't do that though since there is some buffer info kept.
(I think) IMO, that behavior would be a bug.
Jon Mini, j_mini@efn.org, mini@4j.lane.edu
GAMMA Development Team
--------------------------------------------------------------------------
"I think I can, I think I can, I think I can...."
little.blue.engine:Reality Protection Fault. (core dumped)
--------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.960920150137.11965A-100000>