Subject: Re: Tunnel fs idea
To: Robert Evans <email@example.com>
From: Todd Vierling <firstname.lastname@example.org>
Date: 10/02/1997 16:15:01
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
: 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
- 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 email@example.com; Business firstname.lastname@example.org)
== I know you like the Internet, Bobby. Now go eat your Frosted Flakes.