To get some more brains churning eve off of the bug-hunt line of thought,
let me propose something before I go construct it as a LKM.  I guess this is
best termed a gedanken (Thought experiment, a la the King of Relativity).

The portal filesystem is nice, but it lascks some very important vnode calls
to make it a fairly valid file system (readdir among them).  It can defer
the opening of both files and sockets with some permissions restrictions,
but on sockets you can only do a limited set of operations, and on a file
you can't catch some operations "before they happen."  Primarily, the portal
file system is missing too much be a true _file_system_ implemented in
userland code. 

The portal idea lends itself to an extension of that idea--a filesystem
almost completely implemented in userland.  I propose such a file system,
tentatively named "tunnel." 

Operation:

- Kernel receives syscall request, and communicates with tunnel driver
  through AF_UNIX socket (one connect per communication?  one connect at all
  times, with a queue of commands?) and sends packetized commands to the
  userland driver.

- Userland driver receives kernel packets, and does the requested operation.
  In addition, userland driver has the option of creating a file descriptor
  and passing it via cmsg to the requesting process (as a real file or
  socket which the userland driver has no more control over, or an emulated
  channel to the userland driver or other companion program). 

- If a calling program opens a file that results in an "emulated channel" as
  described above, the userland driver or other companion program will
  receive file operations in a similar packetized format from the kernel.
  That includes lseek, read, write, truncate, fstat, etc.

- The tunnel userland driver can be tailored to a particular operation and
  is not bound to use the same semantics as other tunnel drivers, since the
  kernel basically defers filesystem control to the driver.  This could
  result in a /usr/libexec/tunnel_tarfile, /usr/libexec/tunnel_swapfs,
  /usr/libexec/tunnel_gzipfs, /usr/libexec/tunnel_nlist, and so on,
  where each driver has a completely different way of looking at files.

So how does it sound?

=====
== Todd Vierling (Personal tv@pobox.com; Business tv@lucent.com)
== I know you like the Internet, Bobby.  Now go eat your Frosted Flakes.