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: <20080208232038.GL11923@mit.edu>
Date:	Fri, 8 Feb 2008 18:20:38 -0500
From:	Theodore Tso <tytso@....EDU>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH, E2FSPROGS] blkid: Automatically chose between ext4 and
	ext4dev as appropriate

On Fri, Feb 08, 2008 at 04:50:37PM -0600, Eric Sandeen wrote:
> Theodore Ts'o wrote:
> > I plan to release this in an upcoming 1.40.6 release, along with code
> > that allows "tune2fs -E test_fs" to work on ext4 filesystems.  The idea
> > is that if I can get this into community distro's, it will make it
> > easier for them to experiment with ext4/ext4dev, with the appropriate
> > forward compatibility when sometime (hopefully 2.6.26 or 2.6.27?) we
> > rename ext4dev to ext4.
> > 
> > Any comments before I push this change out to the maint branch?
> 
> Seems logically correct to me... although it also seems like this has
> gotten fairly complex by now, what with blkid rummaging around in
> modules.dep, /proc files, etc...

True, but the good thing is that we only need to do this in one
location, and it does the right thing.  It also means that in the
future, even after ext4 is in production, if we want to do some
testing for some new optimizations or other ehancements in ext4, it's
a lot easier for us have both ext4 and ext4dev modules built at the
same time, where ext4dev would have our test code, and then once it's
stable and we're sure it's OK, we can commit it to mainline.  This
makes life much more convenient for an ext4 developer who wants to
both use it in production as well as having an alternate "crash and
burn" ext4dev code that he or she is trying out.

So one of the things that this does mean, is after we do the
ext4dev->ext4 transition, we have some way for users to give us
permission to disable the test_fs bit --- so that in the future, when
we have need of that bit, we can use it again and not have to worry
about old filesystems that are now in production but still have the
test_fs bit set.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ