site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com User-agent: Thunderbird 2.0.0.16 (Windows/20080708) Terry, Joe L. I have a file system kernel module that exposes a remote file system via a file system protocol over a socket. Creating/connecting the socket and performing initial authentication to the server is done in user mode. The socket is then handed to the kernel module via an ioctl to a control device. I have worked out what seem to be the correct kernel calls for this. converting the fd to a socket reference in the kernel module: file_socket sock_retain file_drop using the socket from a dedicated kernel thread: sock_send sock_receive cleanup: sock_shutdown sock_release The primary problem is that the sock_retain and sock_release kernel calls are private exports and are not defined in the public kernel headers. Without these calls the socket will get torn down when the user mode process exits or closes the fd. You could write most of the FS code itself in user space; this is typically what happens for e.g. WebDAVFS for FTPFS. Alternately, you could take a reference on the proc in user space, which would block it from exiting in proc_refdrain() (someone here recently had a problem with this) until you did the proc_rele() on the reference. This would keep the socket around, and you would be, by proxy, using the processes socket. If you can get the socket information out, however, then you don't need to do this, so long as you respect the user space process taking the socket away out from under you. Another alternative is to have a control socket in user space, but have the connection socket set up and torn in kernel space. You could proxy the authentication conversation to user space by reading from the control and writing to the connection, and vice versa, until the conversation was complete, allowing the user space process to exit at that time (and tearing down the control socket). In general, resource tracking is scoped on a per-process basis. While under the covers, it's possible that the implementation details are that the reference scoping is system wide, you generally cannot depend so heavily on the implementation details not changing that you would be able to take something like a socket from process to kernel reference scope, and be assured that this would be sustainable in future releases. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a...

You could write most of the FS code itself in user space; this is typically what happens for e.g. WebDAVFS for FTPFS. Most of the FS code is already in user mode, either in a local file server process on the other end of a domain socket, or on a remote system on the other end of a network socket or some other type of comm channel. Adding a user mode pump to tie the socket to some other comm mechanism will limit performance and will not get a significant amount of additional logic out of the kernel. Alternately, you could take a reference on the proc in user space, which would block it from exiting in proc_refdrain() (someone here ... The arbitrary process that creates the socket needs to be able to exit on its own terms. My main concern is that I do things in the most stable and supportable way. Using a helper daemon to hold an fd open in user mode as a way to keep the kernel socket object referenced is something that had occurred to me, I just consider it convoluted and fragile.

Terry Lambert wrote: On Jul 16, 2010, at 6:54 PM, Joe Lowe wrote: Am I missing something? -- Terry This email sent to site_archiver@lists.apple.com