Messages in this thread | | | Date | Sat, 22 Feb 1997 18:33:09 -0800 (PST) | From | mdean <> | Subject | Remote Device Control Under Linux |
| |
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.
| |