Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Oct 1997 17:54:06 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Cc:        hackers@FreeBSD.ORG
Subject:   Re: zipfs filesystem anyone ?
Message-ID:  <199710231754.KAA27570@usr02.primenet.com>
In-Reply-To: <199710230638.HAA26030@labinfo.iet.unipi.it> from "Luigi Rizzo" at Oct 23, 97 07:38:26 am

next in thread | previous in thread | raw e-mail | index | archive | help
> Thus, I was looking at something which would pass all filesystem
> (or vn ?) calls to some user-space process which could then handle
> them properly. Using this approach, little modifications to, say,
> a standard "unzip" program, would permit such a filesystem to be
> implemented relatively easily.  Efficiency is not a major concern
> for this type of application (especially because the typical use
> would be sequential access to files).

The VFS interface is not reflexive.  Namei would expect your user
space code to free your path buffer allocated in the kernel.  Also
you would have to externalize the lockmgr interface, and alias vnodes
in and out of the kernel, instead of treating them as opaque and using
a user space pointer in the data pointer.  Etc..


Why do you think I go on and on about the VFS layering?  It's not
because I'm an idiot, despite what some people think...


You could do one, but you will have to externalize a hell of a lot
of code, and provide proxy allocation and freeing mechanisms for
every place that is non-reflexive.

I have a device based FS gate for user space FS's, but it assumes
all of my FS changes, and is about 3 months out of sync with -current
8-(.


A better alternative for now might be to build a user space NFS server
at an alternate port (this is what the amd code does; you should look
at it, and "cryptofs" [comp.unix.sources] for more information).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710231754.KAA27570>