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.