Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!agate!helios.ee.lbl.gov!pasteur!ames!oliveb!amiga!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Virtual Memory
Message-ID: <6858@cbmvax.UUCP>
Date: 12 May 89 22:18:09 GMT
References: <9140@polya.Stanford.EDU>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 25

In article <9140@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes:
>Page faulting during Forbid()/Permit() might be acceptable, if the
>page fault handler doesn't modify any standard system structures, just
>the VM state stuff, which sounds reasonable.  Disable()/Enable() may
>or may not be something else again.

	Not really: with that forbid broken (so the device driver task can
run), anything else can get in and cause problems.  For example, if you
Forbid(), FreeMem(), page fault, and the driver AllocMem's, you're screwed.
Hell, if you page fault during AllocMem(), which uses Forbid(), you have REAL
problems.

	It can be done, in all likelyhood, but it's not going to be a slam-
dunk.

	Much easier would be to allow _explicit_ requests for a virtual
allocation, and put the proviso that it must never be accessed during forbid/
disable.  This could be done by third parties.... :-)  Gets you less (only
programs written to use it get any benefit), but is a lot easier.  Oh, one
other proviso: no DMA to it, either (since there is no logical->physical
translation call, and therefor the drivers don't use it).  Mask (for FFS)
will work fine here.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup