From owner-freebsd-arch@FreeBSD.ORG Tue Oct 26 23:31:09 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDCE6106566C; Tue, 26 Oct 2010 23:31:09 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1588FC16; Tue, 26 Oct 2010 23:31:08 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9QNKBHJ013878; Tue, 26 Oct 2010 17:20:11 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <20101026205801.GA39716@zim.MIT.EDU> Date: Tue, 26 Oct 2010 17:20:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <20101026205801.GA39716@zim.MIT.EDU> To: David Schultz X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Kostik Belousov , Ivan Voras , freebsd-arch@FreeBSD.org Subject: Re: Importing the fusefs kernel module? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 23:31:09 -0000 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