z/OS UNIX System Services File System Interface Reference
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Creating, referring to, and closing socket vnodes

z/OS UNIX System Services File System Interface Reference
SA23-2285-00

The PFS creates vnodes by calling osi_getvnode, which is one of the OSI services in the OSIT vector table that is passed to the PFS during its initialization.

Sockets are created by user calls to socket() and accept(). The corresponding vnodes are created during vfs_socket and vn_accept, respectively. vfs_socket creates a socket, and if that socket is connected, a stream session is established to another socket that is created by vn_accept. socketpair() generates a special case of the vfs_socket call that creates two connected sockets. This is similar to the pipe() function.

During vfs_socket and vn_accept, the PFS is expected to:
  1. Set up its socket support and build an inode.
  2. Call osi_getvnode to create a vnode.
  3. Return the vnode token that was returned by osi_getvnode.

The LFS builds the file descriptor, which is also called a socket descriptor, that is the output of the socket() and accept() functions.

Sockets do not have a name in the file hierarchy; consequently, they cannot be opened by POSIX users or exported by VFS servers.

The user program makes socket calls on the file descriptor, and the calling parameters are generally passed straight through to the PFS by the LFS.

Socket descriptors can be inherited over fork(), and they can be duplicated with dup(). The LFS manages this sharing; the PFS is not aware of how many active references to a socket there are.

Eventually the program calls close() for its socket descriptors. After all active references to the socket vnode-inode are closed, the LFS calls vn_close. Because sockets cannot be opened like files, the PFS receives only a single vn_close for any socket.

During vn_close, the PFS severs the user's socket session.

After the vn_close, the LFS calls vn_inactive for the final cleanup of the vnode-inode relationship.

During vn_inactive, the PFS is expected to:
  1. Disassociate the inode from the vnode.
  2. Perform any inode cleanup that is desired.

After the call to vn_inactive, the LFS frees the vnode unless the PFS reports a problem through a bad return code.

Porting note

Because sockets cannot be reused after vn_close, the PFS can combine its close and inactive processing in vn_close, and choose not to support vn_inactive. Nonsupport is not considered a failure of vn_inactive.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014