How to migrate linux kernel to a higher kernel version

Question

I am working on some linux kernel modules & my current kernel is 3.8, I want to upgrade it to kernel 3.10.

I thought of two ways to do it:

1. Either check out a separate 3.10 branch and then merge it with my current 3.8 branch.
2. Or patch 3.8 with 3.9 patch and then patch it with 3.10 patch (patches available on kernel.org are a diff of the current and the previous version, what I believe)

Which approach should I follow? Is there a better way to do it?

I am using git as the version control software.

Answer 1

Well in terms of git you may choose either way.

You may take v3.8 sources, create a separate branch (called, say, my_modules), apply your changes in that branch, commit them. Then you have to merge that branch with the actual kernel sources (I would suggest with upstream master but you may choose any other point (commit) in the kernel development history): git merge <chosen-branch-o-tag-o-commit>. At this point you may have to resolve merge conflicts if any, update your module to the new kernel internal API etc and then commit the merged state. See git merge --help and other relevant git documentation. Now you have your changes adapted to the chosen version of kernel and may see the diff between upstream kernel and the patched one: git diff <chosen-branch-o-tag-o-commit> HEAD. The resulting commit picture would look like this:

A -    ...   - B
 \             \
   D1 - D2... - M

where A is the initial branch point (3.8 kernel), B is the commit you merged with (a newer kernel), D1..DN are your driver's commits and M is the merge.

Alternatively you may also use another approach called rebasing. In this case you "transplant" your initial commits sequence to the new chosen root: git rebase -i B. Then git will try to re-apply the whole sequence D1...DN to the new root B iteratively. Please note that on each step 1...N you may get a conflict which you need to resolve and then continue the rebasing process with git rebase --continue. At the [successful] end you will get a new commit sequence D'1 - D'N growing from B:

A - ... - B
             \
              D'1 - .... D'N

Please note that technically D'1...D'N while looking /similar/ to your original D1...DN are different. They have their own commit time, may have slightly different patch text etc. Depending on your needs they may or may not be what you need.