Date: Tue, 26 Oct 2010 17:20:11 -0600 From: Scott Long <scottl@samsco.org> To: David Schultz <das@FreeBSD.org> Cc: Kostik Belousov <kostikbel@gmail.com>, Ivan Voras <ivoras@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: Importing the fusefs kernel module? Message-ID: <D1BAEBBF-4CD4-4C2A-A877-B86D6322E6C7@samsco.org> In-Reply-To: <20101026205801.GA39716@zim.MIT.EDU> References: <ia4qnl$bgl$1@dough.gmane.org> <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <20101026205801.GA39716@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 26, 2010, at 2:58 PM, David Schultz wrote: > On Tue, Oct 26, 2010, Kostik Belousov wrote: >> On Mon, Oct 25, 2010 at 10:53:08PM +0200, Ivan Voras wrote: >>> Fusefs is the Linux-developed userland filesystem interface which is >>> fairly popular in the wild, especially with the "sshfs" module which >>> allows mounting of generic ssh/sftp directories in a very easy way. >>> >>> It was developed in one of the very early Google Summer of Code projects >>> (2005) and is now in a bit unusual situation: >>> >>> 1) it *is* popular, as reports about its breakage arrive pretty soon >>> after it breaks >>> >>> 2) it is currently practically unmaintained. The source code archive is >>> from 2008 and the port contains a dozen patches to be applied to it to >>> make it work on recent systems >>> >>> 3) it is also not exactly rock stable, though this has improved with the >>> above patches; personally I'd judge it to be as stable as ZFS was two >>> years ago so there :) >>> >>> I'm proposing to import the kernel module into the official tree (there >>> are also userland libraries under the GPL; they will stay as ports). >>> There are no license conflicts for the kernel module. I see two benefits >>> from it: >>> >>> 1) it will finally integrate the patches needed for it to work in one >>> tree and provide the "one official place" to work on it >>> >>> 2) it will be easier to maintain it here, and changes to the VFS APIs >>> would be applied to it in sweeping commits together with other file systems. >>> >>> I'm not knowledgeable enough to actively work on it (yet) but I can >>> mechanically maintain it and generally take care of it. >>> >>> Objections? >> This is not going to work. The code is unmaintained. Committing it into >> the src/ just makes the pile of not working code in src/ bigger. > > I used it about a year ago to grade student projects for a class. > I had a bunch of buggy student code interfacing with the kernel > module via libfuse, and it was quite stable for my purposes. > The project didn't involve supporting mmap, though. > > When I subsequently upgraded my kernel, however, the port broke. > > The value of having FUSE in the tree is that it encourages people > to put forth the modicum of effort required to ensure that it still > compiles when kernel APIs change. I can't comment on whether it is > popular enough to support to such a minimal extent, but it is a > nifty little package: you maintain one kernel module, and you get > passable support for several dozen filesystems for free. What is comes down to is that it needs a committed owner, someone who not only will shepherd it into the tree, but also work on continuous improvements and handle bug reports. I personally think that it would be a good thing to have in the kernel, but I can't afford the commitment. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D1BAEBBF-4CD4-4C2A-A877-B86D6322E6C7>