linux-ext4 - Re: [LSF/MM TOPIC] Drop ext2/ext3 codebase? When?

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:	Fri, 4 Feb 2011 14:59:21 +0100
From:	Jan Kara <jack@...e.cz>
To:	Amir Goldstein <amir73il@...il.com>
Cc:	Eric Sandeen <sandeen@...hat.com>,
	Michael Rubin <mrubin@...gle.com>, Jan Kara <jack@...e.cz>,
	lsf-pc@...ts.linuxfoundation.org, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [LSF/MM TOPIC] Drop ext2/ext3 codebase? When?

On Thu 03-02-11 23:57:25, Amir Goldstein wrote:
> On Thu, Feb 3, 2011 at 9:49 PM, Eric Sandeen <sandeen@...hat.com> wrote:
> Can you give a rough estimate of how those commits diverge between
> bugfixes, kernel API changes, code cleanups?
> 
> Next3 has been following ext3 since 2.6.31 and I remember changes of
> the 2 latter, but not many major bugfixes.
  So I took the work and went through the commit log of ext3 since 2.6.19
(when ext4 was merged). We have
305 commits in total, from those are:
62 cleanups
113 bugfixes
105 changes because of API changing or other kernel-wide efforts
25 features, speedups, and similar

The cathegorization of commits is somewhat arbitrary in some cases but I
think the numbers should be roughly fair...

> I hardly think we can get away with throwing out ext3 code base, but
> maybe it can go into bugfixes-only mode? that is unless Jan likes to
> apply cleanups ;-)
  As you can see, it pretty much is. 25 feature commits in 5 years (and
those features are often like - report mount options in /proc/mounts,
unify error messages, avoid loading bitmap when block group is full, etc.)
is IMHO bugfixes-only mode if you don't want the filesystem to start
bitrotting. I've merged one bigger feature in last year and that was FITRIM
support on the grounds that it did not touch any code outside of FITRIM ioctl
handling itself. So when Lukas wanted to do the work with implementing it,
I was OK with it.

Sure I could be harder on people pushing cleanups on me but I don't want to
scare newbies away so I try to be nice and if the result actually is
better, I take it.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html