From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 15 20:06:35 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E65CB37B401 for ; Fri, 15 Aug 2003 20:06:35 -0700 (PDT) Received: from cirb503493.alcatel.com.au (c211-28-27-130.belrs2.nsw.optusnet.com.au [211.28.27.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8998143FBF for ; Fri, 15 Aug 2003 20:06:34 -0700 (PDT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h7G36Tgh075132; Sat, 16 Aug 2003 13:06:29 +1000 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h7G36R69075131; Sat, 16 Aug 2003 13:06:27 +1000 (EST) Date: Sat, 16 Aug 2003 13:06:27 +1000 From: Peter Jeremy To: Pawel Jakub Dawidek Message-ID: <20030816030627.GB74853@cirb503493.alcatel.com.au> References: <20030814110327.GD395@garage.freebsd.pl> <901731042.20030814215225@centrum.cz> <20030814202909.GK395@garage.freebsd.pl> <20030815084414.GA71116@cirb503493.alcatel.com.au> <20030815090146.GM395@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030815090146.GM395@garage.freebsd.pl> User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org cc: Buckie Subject: Re: GEOM Gate. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2003 03:06:36 -0000 On Fri, Aug 15, 2003 at 11:01:47AM +0200, Pawel Jakub Dawidek wrote: >On Fri, Aug 15, 2003 at 06:44:14PM +1000, Peter Jeremy wrote: >+> >But there are two problems: >+> >1. Device major numbers. >+> >+> I don't see this as a problem - you do the name to major/minor mapping >+> on the remote system. All that goes across the network is the device >+> name (filename in /dev). This is the same way that NFS works. The >+> device major number is just an easy way for the kernel to map a device >+> name onto the device-specific functions to access the physical >+> hardware - this only needs to occur on the server. > >Hmm, I was thinking about something like this: > > # devaccess 192.168.0.2 host1 > # ls -l /dev/host1 > > >And 'devaccess' command will call some kernel mechanism to create new >devices, but all those devices are defined in this way: > > [...] > .d_open = std_open, > .d_close = std_close, > .d_ioctl = std_ioctl, > .d_maj = ?? > [...] > >And std_open()/std_close()/std_ioctl() are functions that only pass >requests to userland daemon, which forwards them to remote host and back. What you've described is a portal. Have a read of "Design and Implementation of 4.4BSD" by McKusick et al for details (my copy is at work so I can't provide an exact reference). They are mentioned in psd/05.sysman and mount_portal(8). There is a PORTALFS in LINT but it's described as "buggy". Note that one downside of this approach is that you are adding two additional userland<->kernel transfers for all the data. If you're looking at passing serious amounts of data to/from a remote device, this inefficiency may become noticable. >+> >2. Handle network errors. >+> >+> I think the easiest way is just to pass them back to the application. >+> This does mean that an application would get unexpected network-related >+> errors, but there's no obvious alternative. > >Or translate all of them to EIO. You probably want to log the real error if you map it to something else. The kernel normally will report details of the error when it returns EIO. Peter