3B2/600 questions

Greg A. Woods woods at eci386.uucp
Sat Nov 25 02:52:15 AEST 1989


In article <1989Nov22.162738.10433 at chinet.chi.il.us> les at chinet.chi.il.us (Leslie Mikesell) writes:
> In article <1262 at atha.AthabascaU.CA> rwa at cs.AthabascaU.CA (Ross Alexander) writes:
> [re: RFS]
> >I _do_ like the way RFS allows sharing periperals like tape drives.
> >That's really handy.
> 
> Actually I think this is a bad idea compared to providing server programs
> that know how to handle both the network and device efficiently.  There
> are also problems with ioctl()'s to devices when the CPU's are different.

Of course you can't share complex peripherals with different systems,
without being *VERY* careful, and without making various changes.

I think that if you take into account the ioctl data is defined by the
device driver, the CPU, the implementation of C, and such, not just
the device itself; you can generate ioctl requests in which the data
has the right number of bits, and the right order of bytes, etc.  You
won't be able to use a curses programme, or a tape rewind programme,
compiled and working on a DEC3100 with a device mounted from a MIPS
(assuming both are running RFS :-), but you might be able to write a
separate ioctl interface for such programmes which will talk to
foreign device drivers, and you should even be able to do it in such a
way that it is user-transparent (find out which filesystems are
remote, stat the device, see if it is remotely mounted, and if it is,
where, and then pick an interface).

So, in the end you will probably want to provide network services
which allow access to shared devices.  Still, in a homogeneous
environment it is nice to be able to mount the other guy's /dev!  As a
very silly example:  it makes more sense to rlogin to another machine
than to disable your tty, and then have the other guy rmount and run
getty on it.  However this example isn't so silly if you want to be
able to balance the load on your machines by transparently shuffling
users between them without getting into a wiring tangle.
-- 
						Greg A. Woods

woods@{eci386,gate,robohack,ontmoh,tmsoft,gpu.utcs.UToronto.CA,utorgpu.BITNET}
+1-416-443-1734 [h]  +1-416-595-5425 [w]    VE3-TCP	Toronto, Ontario CANADA



More information about the Comp.sys.att mailing list