Subject: Tunnel fs idea
To: None <current-users@NetBSD.ORG>
From: Todd Vierling <tv@pobox.com>
List: current-users
Date: 10/02/1997 09:34:53
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.