Date: Tue, 26 Oct 2010 16:58:01 -0400 From: David Schultz <das@FreeBSD.ORG> To: Kostik Belousov <kostikbel@gmail.com> Cc: Ivan Voras <ivoras@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG Subject: Re: Importing the fusefs kernel module? Message-ID: <20101026205801.GA39716@zim.MIT.EDU> In-Reply-To: <20101025211904.GM2392@deviant.kiev.zoral.com.ua> References: <ia4qnl$bgl$1@dough.gmane.org> <20101025211904.GM2392@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101026205801.GA39716>