On Thu, 2 Oct 1997, Robert Evans wrote:

: > 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." 
: 
: That sounds good.  Very good.
: 
: (Re-reading; below I'm talking about "vnode" is the SunOS sense, i.e.
: a filesystem abstraction layer.)

Well, 4.4BSD uses the same concept of vnode, as SunOS is just 4.3BSD on
steroids... ;)

: Just to get it clear in my head, would I be right in saying that what
: you are describing is an interface between the kernel's vnode layer, and
: a userland process "behind" it?

That's correct.  It would basically defer the operations on vnodes to a
userland driver program.

The actual kernel vnode would likely hold a "pointer" (opaque to the kernel,
but passed to the userland driver in communication message packets) to a
structure coordinated by the userland driver that holds actual file and
directory information.  There's also the intriguing possibility of having
that userland driver produce a "real" file or socket that, once opened, is
treated like any other file and not handled by the userland driver at all
until close time.

What could this tunnel driver do?  (This list provided for those who asked
me "why?" via email. ;)

- provide a filesystem that "mounts" a tar file (y'know how useful this can
  be on many distribution media?)

- give the ability to transparently gunzip files on a read-only, no-lseek
  filesystem, leaving libz out of the kernel (Amiga users will recognize
  the analogy name XFH)

- provide a "union mount" /emul/whatever layer that gives more control over
  a binary emulation environment, including an OS-correct /etc/passwd file
  (that supplies full password info only if root opens the file), OS-correct
  pathnames without cluttering the filesystem with symlinks, etc. 

- provide all of the features of the portal fs on an extremely programmable
  and flexible level, along with full getdirentries() ability

- implement proprietary and low-demand filesystems in a more readily
  distributable format (just a tunnel fs "driver module") that needs no
  kernel linkage

- seal the kernel off from file system mishaps (only the affected filesystem
  will fail with something like ENXIO, ENETUNREACH, or ESTALE, instead of
  panicking the kernel) and allow "playing" with a filesystem without the
  danger of a kernel panic

- be easier to program than a custom nfs service (because really, who wants
  to wade through the guts of amd's hlfsd to make a custom userland
  filesystem?  Well, I didn't.  ;)

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