Remote Device Control Under Linux

mdean (mdean@best.com)
Sat, 22 Feb 1997 18:33:09 -0800 (PST)


Please respond to my email address as I am not a member of the linux-kernel
mailing list (my multidrop mailbox does not handle envelope addresses
correctly).

Here is the problem and proposed solution, which one way or the other I
__must__ solve, however I think it could be integrated into the kernel
and/or nfs so I mine as well not expend all my energy just for my own
application. What I can't understand is why no one else seems to need this
facility, or maybye I have just misunderstood nfs or it exists and I cannot
find it (trust me I would much rather use someone elses general code than
hack a specific version for myself), here is my scenario:

Let me first say that Linux is a Robust and dependable operating system and
I appreciate all of you guys (and gals) hard work.

In my organisation I have a particulat application which takes input and
output from some serial devices (force guages, hydralic motors, indicators
etc). I have a cyclades 8 port card which was originally plugged into my
linux fileserver for controlling these serial devices (by the way the
cyclades stuff I really good, and affordable). The client/server suite that
I was working on (where the server is what I am primarily concerned with
here) accesses the serial devices via /dev/cub1, /dev/cub2 etc. using open,
close, fdopen, select, fclose, tcgetattr, tcsettattr, etc. to open serial
devices configure them and wait for input in an efficient manner ---- this
works great as long and the server process that controls all the serial
devices are running on the same machine as the cyclades card --- but lets
remember that we can't go stringing 1000 ft serial cables so when I moved
the fileserver the devices that it controlled (were on an ethernet here)
were too far away. Also I needed X Windows Terminals for the individual
clients that use this server. So I set up a couple of diskless linux
workstations, one i will call master the other slave. Master and slave have
no hard drives and boot from the fileserver via rarp/ root-nfs outfit which
works quites nicely (only thing is that the devices in the root directories
don't get touched correctly when they are used -- which looking at the
source code for utilities like w, and finger which check the last
modification time of these files to calculate idle time, means that users
on the diskless workstations are always show as idle, because of this ?bug?
in nfs implementation).

When the root filesystem is mounted by a diskless workstation over nfs and
then devices in the /dev directory accessed, the devices on the diskless
workstation are being addressed _not_ the devices on the fileserver, this
is a property which we depend on if we expect the diskless workstation to
operate correctly (minus the file modification time problem).

But what I have is a device on a remote system that I want to operate
exactly like a local device --- this makes applications quite portable.
in particular I have my cyclades card connected to a diskless workstation
(slave) --- and I want to access that from my fileserver. I have already
tried nfs mounting slave's /dev directory after it mounts its root
directory from fileserver ---- this __DOES NOT__ work, regardless of the
fact that every time I have asked this question on #linux, I've got some
joke telling me to RTFM on nfs--- I did this, I also contacted the nfsd
porting author (he did not answer back yet though)

Heres my propsed hack:

1. The devd solution.

Write a lightweight server using sockets interface that will allow the
mentioned (tcgetattr, read, etc.) operations to be performed on the remote
machine and the results passed back to the client -- If it turns out to be
just me needing this facillity this is exactly what I will do, and will
integrate the devd client into my server.

2. The device aliasing solution (a portable solution)

I have read the linux kernel hackers guide, but unfortunately till now I
have never needed to write a kernel device driver. What could be done is to
set up /dev/? entries that are controlled by the kernel where the device
driver would access the remote machine perform driver operations etc. and
act make the /dev entry look exactly like a local device i.e.

1. If i perform a "cat /dev/remote0-ttys0" lets say that device is major
239 minor 0, this calls the VFS driver in the kernel, which looks up in
some kind of table (like a routing table) which machine and device that
points to etc. it then calls (lets call it deviod) to query the remote
machines (devd) perform the VFS operation, return the info etc. and spit it
out to cat, etc. The deviod daemon could have a startup file that would
specify what devices on the local machine could be mounted etc. --- this is
starting to sound a lot like nfs --- maybye we could fix that so it would
have the option of assuming devices to be either local or remote etc.,
anyway you see what I am getting at --- I looked at the nfs code but really
for that kind of hack I would need a little help (I am not that familiar
with it (and nfsd/nfsiod would all need to be modified I assume).

Am I missing something here (I don't understand the RPC facillity fully
does it or anything else offer what I am looking for?)

Please Reply to mdean@best.com

Thanks.