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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
