lkml.org 
[lkml]   [1997]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Remote Device Control Under Linux
>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)

The issue is the difference between the way device files operate on UNIX and PC (DOS, OS/2, NT) environments. In the PC systems the device file is the device, so if a network shares the device file then it shares the device. However in UNIX the device file has a single purpose - to tell the kernel the major/minor ID numbers of the device driver. Than after the device file is opened the kernel performs all operations on the local device driver that has registered those numbers.

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

It's probably not just you needing that, although it's not a common need. This is a worthy project that you are suggesting and I am sure that many people will find interesting uses for it once you've written it if you give away source.

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

Changing NFS in that way would not be a good idea. NFS is only designed to operate with block files. You could probably get it to work with a remote device such as /dev/hda1, but to get it to use /dev/cua0 on another machine would be impossible. Also it would be very ugly and violate lots of standards (causing you huge problems if you ever want to upgrade). What you want to do is develop a nice clean solution that either involves no kernel changes, or does the kernel changes in such a desirable way that Linus will integrate it in the main kernel (and save you the effort of maintaining it).

What I would like to know is why you want to do this anyway? Why not just run a program on the remote system? Or do you want to access hardware devices on 2 different machines from the same program?


Russell Coker


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.041 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site