linux-kernel - Re: [PATCH 0/7] OMFS filesystem version 3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200804141020.37271.chris.mason@oracle.com>
Date:	Mon, 14 Apr 2008 10:20:36 -0400
From:	Chris Mason <chris.mason@...cle.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Miklos Szeredi <miklos@...redi.hu>, me@...copeland.com,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 0/7] OMFS filesystem version 3

On Monday 14 April 2008, Christoph Hellwig wrote:
> On Mon, Apr 14, 2008 at 09:16:39AM +0100, Alan Cox wrote:
> > I think the exceed them quite easily. The costs are almost nil, while
> > merging this provides another nice example fs (and one much easier to
> > follow than ext*) for hardware that does have a few users and will no
> > doubt get many more
> >
> > I wasn't aware Linus had introduced a new rule required 500 people sign
> > up to use a feature before it gets added ?
>
> I'm also very surprised by this, especially as it seems to be applied
> very selectively.  This filesystems is an almost 0 maintainance burden
> unlike a lot of really crappy driver we're shoving in constantly.

Thanks to Bob Copeland for taking the time to submit this for mainline.  
Please don't mistake the resulting debate as a sign we don't appreciate the 
effort of making it available and getting it reviewed.

This zero maintenance burden idea is a little suprising to me.  The kernel 
interfaces do change and we either end up changing every filesystem to 
support the new interface or we need to carry around the old ones for the old 
filesystems.

Even though OMFS seems to be using the generic interfaces well, there is still 
a testing burden for every change.  Someone needs to try it, report any 
problems and get them fixed.  Since none of the people making the changes is 
likely to have an OMFS test bed, all of that burden will fall on Bob, his 
users, and anyone who tries to compile the module (Andrew).

Unlike all the device drivers we don't want floating around out of the tree, 
filesystem authors do have a choice between FUSE and being in-kernel.  Since 
OMFS has been maintained out of tree since 2.6.12 or so, Bob probably has a 
very good idea of how much time he has needed to spend updating things for 
each release.

So, there are two big questions I'd ask:

* Which setup (kernel or fuse) would Bob find easier to maintain things?
* Is this a first step toward more development and an increased user base?

Tossing it in -mm isn't a bad step toward getting attention to see if more 
people want to use it.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/