Date: Sat, 16 Aug 2003 13:06:27 +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: <20030816030627.GB74853@cirb503493.alcatel.com.au> In-Reply-To: <20030815090146.GM395@garage.freebsd.pl> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > <list of devices that was exported on 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030816030627.GB74853>