linux-ext4 - My current version of the inline data patches

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: <20130521032657.GB586@thunk.org>
Date:	Mon, 20 May 2013 23:26:57 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	linux-ext4@...r.kernel.org, Zheng Liu <wenqing.lz@...bao.com>
Subject: My current version of the inline data patches

The inlinie data patches, which have been updated to the latest master
branch, can be found here:

https://github.com/tytso/e2fsprogs-inline-patch-queue

or

git://github.com/tytso/e2fsprogs-inline-patch-queue.git

You can look at the history if you want to see what I've done.  The
main thing to note is that while we are maintaining patches in a patch
series, and while we are still trying to clean up the function
interfaces, to fold any changes into parent patches.

So for example, I've folded all of the gcc -Wall cleanups that had
been in "libext2fs-fix-some-warnings-from-gcc-Wall" into the patches
that introduced the gcc warnings.  This makes it easier to review the
patches, since we don't have the problem of a patch which has bugs or
warnings which is fixed in a later patch.

When I did that, I found a change which was not related to gcc -Wall
cleanups hiding in that patch.

I think I remember seeing other places where unrelated changes were
glommed together into a single patch.  As we find them, we should
split them into separate patches, again for ease of patch maintenance
and improvements.

Again, my apologies for taking so long in getting these patches out
there.  I really wanted to give you some examples in the kind of patch
factoring and interface cleanups that I was hoping for before merging
this support upstream.  Unfortuantely, I've been crazy busy these last
few weeks.  I had hoped to put more work into this today, but I lost
at least two hours due to a burst gas main which forced the
evacuations of the offices.  :-(

(Turns out it's not just network fibers which emit backhoe pheromones,
gas mains do as well.  :-)

I'll let you take the next whack at improving the patches.  My
suggestion is that you create your own github repository, and update
the patches using git.  What I generally do is to apply the patches
using guilt (I suggest using v0.35 from git://repo.or.cz/guilt.git) by
pulling down the github repository into an e2fsprogs repository at
".git/patches/inline".  Then take a look at first line of
.git/patches/inline/series, which currently reads:

# BASE 4cf7a7014a209b82aada9b5d83ecdb9b07e60a1a

In the top of the e2fsprogs repository, type the commands:

% pushd .git/patches/inline ; sh timestamps ; popd
% git branch inline 4cf7a7014a209b82aada9b5d83ecdb9b07e60a1a
% git checkout inline
% guilt push -a

This will apply all of the patches in .git/patches/inline (which you
pulled down from github) to the e2fsprogs tree.  You can go back and
forth by using the commands "guilt pop" and "guilt push".  To modify a
patch, just edit the e2fsprogs files, and then use the command "guilt
refresh --diffstat" to merge your edits into the patch file.  You can
then commit changes to the patch queue by cd'ing into
.git/patches/inline directory, and running standard "git commit"
commands.  This way, when you send me an updated set of patches, I can
look at the git log to see what changes you've made.

Does this make sense?  If not, please feel free to send me any
questions you have.

Thanks,

						- 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