When the NFS server processes a request, there are two basic pieces of
information it needs to decide whether to grant the request: it must know *who*
the client is, and it must know *what* they are trying to access.  Given these
two pieces of information, it can make the access decision using the exports
table.

This process involves cooperation between the userspace and the kernel; it
is userspace that knows the export table (given by the administrator using
exportfs or the /etc/exports table), and that can resolve domain names
(possibly necessary to determine identity) but the nfsd code is all in the
kernel.

The relevant kernel code is in net/sunrpc/rpc/, include/linux/sunrpc/,
fs/nfsd/, and include/linux/nfs*.  The relevant userspace code is in
the nfs-utils package.

The association of a client identity with an incoming request is done by the
rpc server code, by the "accept" operation that is defined by every server-side
authentication method.  In the case of auth_sys and auth_null, this is a matter
of mapping the source IP address on the incoming request to a client name.  A
"client name" here refers to the string used on the exportfs commandline, or in
the /etc/exports file; thus an incoming request may map to a string like
"*.citi.umich.edu".

[ XXX mount process--nfsv3 vs. nfsv4; export caches; etc.]