On Sat, 27 May 2017 21:59:54 +0800, Yun-Chih Chen said:
What I did is: 1. Checkout to a commit near 2011/7/18 (the latest commit at the time the patch was sent) 2. Cherry-picked the three commits from tracing/mm 3. Apply the patch
I failed at step 3.
Anyone has any suggestion on this?
Step 0: Ask yourself whether 6 year old code is still relevant. For starters, look at Mel Gorman's comments: https://lkml.org/lkml/2011/7/29/85 Step 1: Double-check that you applied all 5 patches in the series, in the correct order. Step 2: Ask yourself if your knowledge of C is up to actually changing code rather than just applying patches and praying. Some patch issues are pretty obvious and can be cut-and-pasted into working, others you'll need to do some actual programming to fix things. Step 3: Look at the .rej reject files that patch leaves, or the <<< === >>> conflict markers if git fails to merge a patch cleanly. Figure out if there's only 1-2 small rejects or if you have 5,384 conflicts that look like one side was written in C and the other in Jovial. Step 4: One by one, manually resolve the conflict(s). Often, this is due to other unrelated changes adding or removing or changing a line within the context area of the rejected section of the patch, and it's obvious how to hand-apply the change. Sometimes, it's due to an API change, so you'll have to understand what got changed, and possibly re-work the patch a bit. You'll be pretty much on your own here, because there are approximately zero kernel developers that remember the how or why of an API change from years ago. Step 5: Test. Prove the patch (a) works and (b) is actually useful. Step 6: Rework the patch to apply to a current kernel like 4.11 rather than a 3.0 kernel from 6 years ago. This is usually the tough part. Step 7: Read Documentation/process/submitting-patches.rst and submit the patch so you don't need to keep re-basing it yourself at each new release.