From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 15 01:44:28 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 B35D037B401 for ; Fri, 15 Aug 2003 01:44:28 -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 0B42243FAF for ; Fri, 15 Aug 2003 01:44:27 -0700 (PDT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h7F8iJgh071247; Fri, 15 Aug 2003 18:44:19 +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 h7F8iE28071246; Fri, 15 Aug 2003 18:44:14 +1000 (EST) Date: Fri, 15 Aug 2003 18:44:14 +1000 From: Peter Jeremy To: Pawel Jakub Dawidek Message-ID: <20030815084414.GA71116@cirb503493.alcatel.com.au> References: <20030814110327.GD395@garage.freebsd.pl> <901731042.20030814215225@centrum.cz> <20030814202909.GK395@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030814202909.GK395@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: Fri, 15 Aug 2003 08:44:29 -0000 On Thu, Aug 14, 2003 at 10:29:09PM +0200, Pawel Jakub Dawidek wrote: >On Thu, Aug 14, 2003 at 09:52:25PM +0400, Buckie wrote: >+> BTW, QNX had this for a long time, it's called QNet in there. Allows >+> transparently to mount or use anything in /dev. Even a soundcard! > >I think this isn't really hard to implement. I tend to agree. I've done some background thinking about this in the past couple of months and couldn't come up with anything especially difficult - though deeper thought may reveal something. The logical implementation is either as a pseudo-filesystem - aka devfs(5) - or (more cleanly) a portal. >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. >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. I can think of a third potential problem: Handling ioctl()s where the third argument is a pointer to a structure that itself include pointers to other data objects. This would require special casing those ioctls. (Worse would be SysV-style ioctl's which don't comply with the BSD request encoding). Peter