Date: Fri, 24 Oct 1997 11:25:59 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Terry Lambert <tlambert@primenet.com> Cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, hackers@FreeBSD.ORG Subject: Re: zipfs filesystem anyone ? Message-ID: <Pine.SV4.3.95.971024111008.17710C-100000@parkplace.cet.co.jp> In-Reply-To: <199710231754.KAA27570@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 23 Oct 1997, Terry Lambert wrote: > 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.. [..] > 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. [..] > 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). Wouldn't you have to externalize a lot of stuff anyway? We'd need some extra syscalls along the lines of John Heidemann's ook* (Out Of Kernel) stuff. You can make a fs specific call that serves as a general interface to marshall fs related operations in and out of the kernel. Then you can make a semantic-free user layer. It seems that a lot of NFS related work these days have to do with adding state. I was looking at this a few months ago after John H. released his layering code. It also seems that Poul and John Dyson have started cleaning up some fs related interface and memory issues, but I haven't had time to examine all the details. Regards, Mike Hancock > > 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?Pine.SV4.3.95.971024111008.17710C-100000>