The main difference between a DFS-style server, called a file exporter here, and an NFS-style server is that a file exporter controls both local and remote access to the file systems that it exports. It does this through the use of an exit program that is specified at the time the exporter registers with v_reg().

A file exporter exports entire mounted file systems with the v_export() function. Usually the exporter is set up with a list of file systems that it is to export, and these are exported during initialization.

An exported file system is made known to the network in general. End users at DFS-style clients access all network files through a single "DFS" mount point on their system. The clients call a name server to find files that they are interested in, and so they are not affected when the files are moved. This differs from an NFS-style client, whose user individually mounts directories from each remote system on particular local mount points. The location of the directory, and thus the files under it, is specified at mount time, and so cannot be changed without changing the mount at each client.

For vnode operations that do not originate with the file exporter itself, an exporter exit program is used to synchronize file changes. The exporter exit program is invoked before and after every vnode operation that is called for files within an exported file system. The exit program communicates with the file exporter to coordinate file sharing between local users and remote clients. In effect, the exit program is serving as a "DFS client" for all the local users of the exported file system. Only tokens that grant permission to continue with the vnode operation are transferred via the exit, and not file data. In this way the exit and file exporter ensure that when a local program reads a file it will see all changes that may have been made to this file by remote clients.

The interface between the LFS and the exporter exit is the GXPL structure. Refer to Interface structures for C language servers and clients for the structure itself and the C prototype of the interface.

The exit program receives control in the kernel address space and in the following environment:

Registers at Entry. The contents of the registers on entry to the exit are:

Environment at Exit. Upon return from the exit, the entry environment must be restored as follows:

Registers at Exit. Upon return from the exit, the register contents must be