linux-kernel - Re: 2.6.29 -mm merge plans

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]

Date:	Wed, 7 Jan 2009 13:21:42 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-fsdevel@...r.kernel.org
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org,
	Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>
Subject: Re: 2.6.29 -mm merge plans

On Wednesday 07 January 2009 10:28:29 Andrew Morton wrote:
> Christoph Hellwig <hch@...radead.org> wrote:

> > BTW, the current influx of higher-complexity filesystems certainly
> > worries me a little.
>
> Well yes.  Each new filesystem (complex or not) is an additional
> boatanchor on development of core kernel: block, vfs, MM, etc.  So each
> filesystem should be justified on the basis that it adds sufficient
> benefit to justify that cost.  (And I got mau-muaed for pointing this
> out in the omfs context, I might add).

I've found that if the filesystems have active maintainers who are willing
to help eg. if some MM APIs need to change, then it isn't such a big problem.

It simply doesn't scale and will not work if an MM developer is expected to
go through and try to understand *every* filesystem, attempt to change them,
and test them even though it's non-trivial to even set up and mount a lot
of these things to test them.

Each individual filesystem development community already knows their fs code,
has test environments set up (or presumably can at least mount the thing),
and only need to understand one little changed aspect of the MM, with the
help from the MM developer.

Latter system is efficient and scales, former does not.

If a filesystem is merged it has to have a pretty good promise that it will
be well maintained. (obviously it still has to justify a cost, but that cost
becomes sane)

> Will nilfs bring enough value to justify it's cost?  Hard call.  What
> do you think?
>
> (otoh, we could probably randomly delete ten old filesystems and
> practically nobody would notice)

I don't know how stable fuse APIs are (ie. whether we'd just be handing the
anchors to FUSE), but if it is very stable, then it would be nice to push a
lot of them out of the kernel (although OTOH the old ones tend not to have
complex interactions with mm or block layer).

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