Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!udel!new From: new@udel.EDU (Darren New) Newsgroups: comp.sys.amiga.tech Subject: Re: Virtual Memory / doable 1.4 request Message-ID: <15935@louie.udel.EDU> Date: 21 May 89 18:29:40 GMT References: <8905181730.AA08602@postgres.Berkeley.EDU> <11756@well.UUCP> Sender: usenet@udel.EDU Reply-To: new@udel.EDU (Darren New) Organization: University of Delaware Lines: 19 In article <11756@well.UUCP> farren@well.UUCP (Mike Farren) writes: >1. Add a new protection bit - 'v'. (Or other mechanism - something > >I'm assuming that this is naive - it's certainly off-the-cuff. Do you >see problems? Sure. What about code that wasn't loaded from a file? How about libraries, fonts, device drivers, etc? Where are you going to keep this default info? If you keep it in the task structure, then libraries will wind up allocating (say) virtual when they can only work with physical or vica versa. If you have a device driver, doesn't the I/O-Quick flag allow the possibility of the request completing in the callers task rather than the device-driver's task?What about printer drivers, which have different parts loaded from different files? If you can handle all of these problems, you probably don't need to hook anything to the files to start with. Goodness, you would think this was Unix-land, where every process has an associated file... :-) :-) -- Darren