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.
-------