GEOM Gate.

Pawel Jakub Dawidek nick at garage.freebsd.pl
Fri Aug 15 02:01:39 PDT 2003


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.

+> >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.

-- 
Pawel Jakub Dawidek                       pawel at dawidek.net
UNIX Systems Programmer/Administrator     http://garage.freebsd.pl
Am I Evil? Yes, I Am!                     http://cerber.sourceforge.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20030815/129a999e/attachment.bin


More information about the freebsd-hackers mailing list