From owner-freebsd-hackers Sat Sep 20 15:08:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA29363 for hackers-outgoing; Sat, 20 Sep 1997 15:08:31 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA29358 for ; Sat, 20 Sep 1997 15:08:27 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA00982; Sat, 20 Sep 1997 15:08:20 -0700 (MST) From: Terry Lambert Message-Id: <199709202208.PAA00982@usr02.primenet.com> Subject: Re: UserLand Device Driver Thingys To: jamil@counterintelligence.ml.org (Jamil J. Weatherbee) Date: Sat, 20 Sep 1997 22:08:20 +0000 (GMT) Cc: nate@mt.sri.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Jamil J. Weatherbee" at Sep 20, 97 01:43:12 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Are you saying that I can tunnel /dev/cuaa0 from another machine over to > the local machine seamlessly. No, he's not. Unless you are willing to write the tunneling code. Actually, devfs deals with this. Because the namespace for devices is the directory namespace instead of the major/minor namespace in a devfs system, it should be possible to export devices by exporting devfs. The main problems are: 1) Homogeneous access only -- device paramaters vary between OS implementations 2) NFS is inadequate to the task; it can not proxy ioctl() data and data responses between machines. This is actually a failing in NFS, since it's not a real hard problem, so long as you break the VFS/NFS connection at the right place, but again, it's ngoing to make it unportable. You could, of course, write your own proxy service and client device, if you wanted. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.