Modulo the "new system call" that's fallen out of this
thread, I did exactly what you originally reported
you'd done (cleaning up the exporting code, centralizing
export checks, etc) some years back.  I've been meaning
to try to get the company for whom I'd done that work
to release it, but...well...they went out of business,
and I didn't want to do the legwork to free the intellectual
property, as it were.

Anyhoo, some wis-dumb I'd like to pass along: you may want to keep the
export-checking mechanism itself pluggable, so you can swap in/out
that part of the code that decides whether any given filehandle can
be referenced by a client.  This lets you drop in Solaris-style
exporting (on a per-directory tree, per CIDR block) alongside some
Kerberos-based authorization mechanism alongside the traditional
BSD mechanism of exporting (per mountpoint, per CIDR block).

My implementation did the obvious and hung another vtbl-like
vector of function pointers off each mount point.  From memory,
the entry points were things like "check this file handle for
client access," "here's a chunk of data, figure out how to
parse it into your special rules for allowing client access,"
and so on.

Mind you, I never did actually *implement* an auth mech other
than one like Solaris's, but my thinking was that a mount
option would pick which mechanism to use.  In the new world,
I guess that'd be just another call to the proposed fsctl().

If you're already grotting around in that part of the code,
I think it'd be easy enough to make what you've done be
pluggable, so that different sets of exporting rules could
be used.  I only mention it as something to consider.  Too,
I guess I also claim an existence proof that it can be done,
and that doing it was once thought to be sensible by folks
who've been where you are now.

Chris <jepeway@blasted-heath.com>.