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=20= >>> fairly popular in the wild, especially with the "sshfs" module which=20= >>> allows mounting of generic ssh/sftp directories in a very easy way. >>>=20 >>> It was developed in one of the very early Google Summer of Code = projects=20 >>> (2005) and is now in a bit unusual situation: >>>=20 >>> 1) it *is* popular, as reports about its breakage arrive pretty soon=20= >>> after it breaks >>>=20 >>> 2) it is currently practically unmaintained. The source code archive = is=20 >>> from 2008 and the port contains a dozen patches to be applied to it = to=20 >>> make it work on recent systems >>>=20 >>> 3) it is also not exactly rock stable, though this has improved with = the=20 >>> above patches; personally I'd judge it to be as stable as ZFS was = two=20 >>> years ago so there :) >>>=20 >>> I'm proposing to import the kernel module into the official tree = (there=20 >>> are also userland libraries under the GPL; they will stay as ports).=20= >>> There are no license conflicts for the kernel module. I see two = benefits=20 >>> from it: >>>=20 >>> 1) it will finally integrate the patches needed for it to work in = one=20 >>> tree and provide the "one official place" to work on it >>>=20 >>> 2) it will be easier to maintain it here, and changes to the VFS = APIs=20 >>> would be applied to it in sweeping commits together with other file = systems. >>>=20 >>> I'm not knowledgeable enough to actively work on it (yet) but I can=20= >>> mechanically maintain it and generally take care of it. >>>=20 >>> 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. >=20 > 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. >=20 > When I subsequently upgraded my kernel, however, the port broke. >=20 > 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>