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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.DEB.1.10.0804141326020.13255@asgard>
Date:	Mon, 14 Apr 2008 13:29:29 -0700 (PDT)
From:	david@...g.hm
To:	Chris Mason <chris.mason@...cle.com>
cc:	Christoph Hellwig <hch@...radead.org>,
	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 Mon, 14 Apr 2008, Chris Mason wrote:

> 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.

seconded.

> 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.

switching to FUSE also has a cost for users, namely that they need to have 
FUSE setup (and the various interactions and deadlocks that can happen 
with a userspace filesystem, such as swapping to it)

as a user I would prefer to see filesystems (even ones I don't expect to 
uer) be all treated the same way, not have to figure out that to use this 
list of filesystems I configure them in the kernel, and to use that list 
of filesystem I have to run FUSE.

for testing, or for things that aren't really filesystems (views into 
version control systems, tarballs, etc) FUSE is a good match.

but for real filesystems it's a poor second.

David Lang

--
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/