From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 00:46:58 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 BC4F4106564A; Wed, 27 Oct 2010 00:46:58 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 275DB8FC16; Wed, 27 Oct 2010 00:46:57 +0000 (UTC) Received: by wwb24 with SMTP id 24so97114wwb.31 for ; Tue, 26 Oct 2010 17:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=SzsaPbE+9hHZ5RfQAWkoBHJ0gk28zsBG+hSaF0KhYt0=; b=Uqofqyr6dq42DwsJUKECp59VBaFyrFFBPAA1H3vMK+6Bg/4QwSID9M2jTEAKZ6wQHt nVu5AvKK8IUfsK5mVZVySwkNgzhduKxPNrOdz5S3CmpVLg9R77GdId2bChQb68N/doB+ gfYZeUkPTj6KH3V1xOmJWh6jrHPc2+cGm8ksM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=C9+7Ap6fCLo64ciq/ql2SeZjIirZkAZJmvUW+7QtI6Djwg4nW9wMZtsuSBU2cVhiep SAr0ajRpMwKYJn+U/C9j0/m/aUWC/n5FXAcXYbC+SpdenOTV0AUuHfwG9O90IGuRYizf +eE60ncjX3bXlILRMzuQ095vu3ABTvf5UEUxw= MIME-Version: 1.0 Received: by 10.227.155.11 with SMTP id q11mr114394wbw.130.1288138931355; Tue, 26 Oct 2010 17:22:11 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.10.198 with HTTP; Tue, 26 Oct 2010 17:22:11 -0700 (PDT) In-Reply-To: References: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> <20101026205801.GA39716@zim.MIT.EDU> Date: Tue, 26 Oct 2010 17:22:11 -0700 X-Google-Sender-Auth: 4oFZjc9u-sYPVHI4XZ30-NrB7gc Message-ID: From: Garrett Cooper To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , David Schultz , 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: Wed, 27 Oct 2010 00:46:58 -0000 On Tue, Oct 26, 2010 at 4:20 PM, Scott Long wrote: > 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 projec= ts >>>> (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 i= s >>>> 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 t= he >>>> 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 (ther= e >>>> are also userland libraries under the GPL; they will stay as ports). >>>> There are no license conflicts for the kernel module. I see two benefi= ts >>>> 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 sy= stems. >>>> >>>> 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. =A0I 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 improveme= nts and handle bug reports. =A0I personally think that it would be a good t= hing to have in the kernel, but I can't afford the commitment. If this module was in the tree, could we drop other less maintained filesystems, like our in-tree ntfs support (/sys/fs/ntfs/)? I know it sounds radical, but it would be nice to have a working filesystem instead of a filesystem that's out-of-date and broken like our in-tree ntfs. Also, what about our hfs / hfs+ support? I haven't checked lately (and I'll confirm when I get home), but it looks like support might be a bit shaky ( https://forums.freebsd.org/showthread.php?t=3D1198 ). I wouldn't mind having good filesystem support for my PowerPC Mac and iPod :). There are some other handy filesystems like sshfs, etc that people have rolled for other purposes that would be interesting to have access to. So I would be game to help maintain things, but I'd need help getting up to speed on FUSE and figure out the lay of the land. I wouldn't be very effective for a while though because I'm not knowledgeable in the ways of the vfs[, yet?].. Thanks, -Garrett