Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!botter!star.cs.vu.nl!ast
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: A Client/Server Version of MINIX for 68000
Message-ID: <1593@ast.cs.vu.nl>
Date: 30 Oct 88 10:44:31 GMT
References: <113@bsadrc.UUCP>
Reply-To: ast@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 26

In article <113@bsadrc.UUCP> usenet@bsadrc.UUCP (Darrel R. Carver) writes:
>I am now curious about a couple of points.  Consider the following 
>scenario:
>
>[1] I purchase a stripped down version of the ATARI ST (i.e. the
>    minimum configuration of the 1M ST with no hard drive). 
>[2] Buy PH's new version of MINIX for the ST
>[3] Recode the FS module of MINIX to use part of the 3B1 as a file
>    server.
>
There is no conceptual reason why that couldn't work.  The MINIX-PC 1.3
version comes with Ethernet support for remote execution, and there is an
example in there about one way of making a remote file system.

I think the idea of hacking FS to have it forward messages to a remote server
is definitely feasible.  There are a few things to watch out for, such as pipes
and terminals.  You probably don't want reads on the tty forwarded to the remote
server, and unless the local machine keeps some information about inodes
around, it won't know what is a tty, what is /dev/mem etc.

The key question is where to make the split between local and remote.  Do you
want all the inode management stuff local, remote, or both, for example?
I haven't really thought this out in detail, but I am reasonably convinced
that it can be done.

Andy Tanenbaum (ast@cs.vu.nl)