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