Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!A.CC.UMICH.EDU!rees From: rees@A.CC.UMICH.EDU (Jim Rees) Newsgroups: comp.sys.apollo Subject: Re: Apollo's NFS !! Message-ID: <8806281619.AA07520@a.cc.umich.edu> Date: 28 Jun 88 16:00:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: rees@caen.engin.umich.edu (Jim Rees) Organization: The Internet Lines: 30 I simply want to store Apollo executables on an NFS-mounted disk and have an Apollo execute them from that disk just as if they were on a local disk or on a disk accessed via DOMAIN. The NFS client code is implemented on the Apollo side as an extensible streams type manager (see my Atlanta Usenix paper). This means anything that goes through the I/O system (open, close, read, write) can use NFS. But programs aren't loaded through the I/O system. They are loaded through mapped files, which is at a lower layer (I/O to normal disk files is done by mapping them). The fix for this is obvious but not trivial to implement. What's needed (in my opinion) is an "exec" trait, whose operations would be things like "load text into memory." The domain disk file manager would do this the way it always has, by directly mapping the file and paging out of it. The NFS manager would have to copy the text and initialized data into a temp file, which is a little yucky (you wouldn't get demand paging) but would work. To get demand paging, you would have to layer the paging system on top of NFS, instead of the other way around as it is now. This would not be easy since you'd also have to re-layer TCP (ok, IP/UDP). The fact that the compiler won't deliver code into an NFS receptacle is just a plain, ordinary bug, one that I hope gets fixed sometime soon (maybe I should learn how to file a UCR?) I know that this explanation doesn't help solve your problem, but I thought some of you might be interested anyway. -------