Subject: Re: unix domain sockets with open() ability?
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Todd Vierling <tv@pobox.com>
List: current-users
Date: 09/24/1997 12:37:16
On Tue, 23 Sep 1997, der Mouse wrote:
: > - rewriting sys_open() into two segments that does a vfs lookup to a
: > locked vnode beforehand in the nameidata struct, then calls
: > vn_open(), which has been modified to check for the presence of an
: > already locked vnode in the nameidata struct... but skips calling
: > vn_open() and opens a socket instead for a vnode of type VSOCK
Yecch. This doesn't work either, really. If a vnode is in nameidata, it's
assumed a namei lookup is in progress and it's aborted, so that structure
element is unusable as a "trapdoor".
Lessee, another flag bit? Too much expense to use on this application.
Short of duplicating a modified vn_open() inside of sys_open(), this is much
more painful than I thought. Ick! The only alternative I can see is this:
- config option to turn on openable AF_LOCAL/AF_UNIX sockets and compile in
the required couple lines in vn_open() and the uipc_vnops.c file;
- a set of vnode v_ops in a uipc_vnops.c that translate vnode operations
into socket operations. The socket would then, after opening, look like a
file instead of a socket, which could be a plus. Even internal vnode
operations in the kernel would then work on them, and they could refer to
the parent directory and name of the actual listening socket;
- possibly have sys_open() detect the special case of a VSOCK returned by
vn_open(), and drop the VNODE while placing the socket directly into the
file descriptor. I'm leaning away from this because of the advantage of
making the socket look like a file if open()ed;
- possibly in the future to implement pseudo seek/trunc/etc. that would be
"controlled" by the stream's creator.
Stoke the brainstorm fire some more if desired. <grin>
=====
== Todd Vierling (Personal tv@pobox.com; Business tv@lucent.com)
== I know you like the Internet, Bobby. Now go eat your Frosted Flakes.