Date: Fri, 15 Aug 2003 18:44:14 +1000 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Pawel Jakub Dawidek <nick@garage.freebsd.pl> Cc: Buckie <freebsd1@centrum.cz> Subject: Re: GEOM Gate. Message-ID: <20030815084414.GA71116@cirb503493.alcatel.com.au> In-Reply-To: <20030814202909.GK395@garage.freebsd.pl> References: <20030814110327.GD395@garage.freebsd.pl> <901731042.20030814215225@centrum.cz> <20030814202909.GK395@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030815084414.GA71116>