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]

Message-Id: <20090106152829.43dab4a0.akpm@linux-foundation.org>
Date:	Tue, 6 Jan 2009 15:28:29 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	linux-kernel@...r.kernel.org,
	Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>
Subject: Re: 2.6.29 -mm merge plans

(cc added)

On Tue, 6 Jan 2009 17:57:44 -0500
Christoph Hellwig <hch@...radead.org> wrote:

> On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> 
> > nilfs2-add-document.patch
> > nilfs2-disk-format-and-userland-interface.patch
> > nilfs2-add-inode-and-other-major-structures.patch
> > nilfs2-integrated-block-mapping.patch
> > nilfs2-b-tree-based-block-mapping.patch
> > nilfs2-direct-block-mapping.patch
> > nilfs2-b-tree-node-cache.patch
> > nilfs2-buffer-and-page-operations.patch
> > nilfs2-meta-data-file.patch
> > nilfs2-persistent-object-allocator.patch
> > nilfs2-disk-address-translator.patch
> > nilfs2-inode-map-file.patch
> > nilfs2-checkpoint-file.patch
> > nilfs2-segment-usage-file.patch
> > nilfs2-inode-operations.patch
> > nilfs2-inode-operations-fix.patch
> > nilfs2-file-operations.patch
> > nilfs2-directory-entry-operations.patch
> > nilfs2-pathname-operations.patch
> > nilfs2-pathname-operations-fix.patch
> > nilfs2-operations-for-the_nilfs-core-object.patch
> > nilfs2-super-block-operations.patch
> > nilfs2-super-block-operations-fix.patch
> > nilfs2-segment-buffer.patch
> > nilfs2-segment-constructor.patch
> > nilfs2-recovery-functions.patch
> > nilfs2-another-dat-for-garbage-collection.patch
> > nilfs2-block-cache-for-garbage-collection.patch
> > nilfs2-ioctl-operations.patch
> > nilfs2-update-makefile-and-kconfig.patch
> > #
> > nilfs2-fix-problems-of-memory-allocation-in-ioctl.patch
> > nilfs2-cleanup-nilfs_clear_inode.patch
> > nilfs2-avoid-double-error-caused-by-nilfs_transaction_end.patch
> > nilfs2-insert-explanations-in-gcinode-file.patch
> > nilfs2-add-maintainer.patch
> > nilfs2-fix-gc-failure-on-volumes-keeping-numerous-snapshots.patch
> > 
> >   Dunno.   Has this been reviewed enough?
> 
> No.  I might eventually take a look, but looking into btrfs has a little
> higher priority right now, and split into gazillions of
> non-selfcontained patches certainly doesn't help reviewing it.

nilfs will remain under development for a couple of months and we'll
take a look at a 2.6.20 merge.  Can you please find time to take a
closer look during this cycle?

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

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