diff options
| -rw-r--r-- | 00-README | 122 |
1 files changed, 122 insertions, 0 deletions
diff --git a/00-README b/00-README new file mode 100644 index 0000000..5a10d0a --- /dev/null +++ b/00-README @@ -0,0 +1,122 @@ +Overview: +--------- +This is a repository of patches to make an RT kernel. The patches largely +all originated from the "tip" repository: + + git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-tip.git + +in the branch rt/2.6.33. The RT content in the tip git repo was +originally based on 2.6.31, and then the newer kernel.org content +was merged in. Merge commits are not easy to review/digest, and if +a functional change/addition was embedded in a merge commit, then +you'll have a hard time seeing it at all, unless you explicitly go +looking for it. + +So the goal was to have a linear, merge-free set of commits that are +historically faithful to the original changes, but that stack on top +of the current 2.6.33.7 baseline to give you the *exact* same source. + +Changes that were "hidden" in merge commits were either re-parented +to an existing changeset, or extracted to be visible stand alone +changesets in their own right -- depending on which made more sense. + +Then carry forward to the newer 2.6.34.x kernel would also be easier, +since it was clear which changes were being isolated and rebased onto +the new baseline. + +The result will be familiar with long time RT users, in that you get +a series file, and a list of patches it applies, and you can use your +tool of choice to apply them (git-am, quilt, git-quiltimport, etc.) + +This repo is normally located here: + + http://git.kernel.org/?p=linux/kernel/git/paulg/rt-patches.git + + +Branch/tag Usage: +----------------- +Branches follow the normal "stable" like strategy. The master branch +is for kernels released by Linus, i.e. 33, 34. (the implicit .0 release) +The master branch currently stops at v2.6.34 flat, i.e. 2.6.34.0 so to speak. +At this point in time it is unlikely that I will carry it ahead to v2.6.35 + +Then for kernels which are in themselves branches from master (like all +the 34.x, with x>0) are on their own branch, namely v2.6.34-rt. This is +the branch you want to use if you are using a the latest 2.6.34.x kernel. + +There are over 400 known working RT enabled bisection points (as tags) +between 33 and 34 that you can make use of for testing. The details +on how/why those exist follows - read on if it is of interest to you. + + +Applying the patches: +--------------------- +There is a series file, listing the patches and the order they need +to be applied with. You can use this with quilt, or you can use +git directly with something as simple as this: + + cat `grep ^[a-zA-Z0-9] series` > /tmp/foo.mbox + git am /tmp/foo.mbox + + +Carry Forward from 33 to 34: +---------------------------- +This warrants some notes, since (a) it has strong consequence on how +you can diagnose/bisect problems that were not in 33-rt but may exist +in 34-rt and (b) we've recently seen people who wonder how to do a +similar task and I think they *really* underestimate the complexities +and sheer effort of trying to do any sort of RT carry-forward. + +Step one was that I needed the RT commits rebased against 33 (and not 31) +as my starting point for rebasing RT onto v2.6.34 -- see the above +disscussion for details on that. + +There are roughly 500 RT patches, and literally 10,000+ commits between +v2.6.33 and v2.6.34. So if one was to move things ahead all in one go, +there can be roughly 5 million things that can go wrong. Maybe some sharp +person can move those ahead all in one shot, and then figure out the +resulting inevitable runtime breakage, but that isn't me. + +Knowing that the RT patches applied (and worked) on base X, but fail to +apply or fail to work on X+N (where N is small) can be very empowering +to a dumb person like me. It reduces the problem space *immensely* and +it lets you focus on what changed and caused the problem/conflict. With +that in mind, I saw no choice but to undertake what would have been the +equivalent of recreating history, had a continuous integration between +the two streams taken place during the 33 --> 34 dev cycle. + +What this means in concrete terms, is incrementally applying, updating, +and testing the 500-odd RT patches at successive points along the 10000 +commits found in the 33 --> 34 development cycle. But assuming you +agree with that logic, what does a person choose/use as increments? +At a 1st guess, a person might suggest choosing the rcN tags (where we +have N=1,2,... 7) as places for these incremental tests. The problem +is that the granularity is too coarse -- just for N=1 means you have +already jumped over 6000 commits ahead, and so you are still facing +being lost for the same reason 10000 commits left you lost before. +At the opposite end of the scale is a brute force approach, where a +person tries applying/updating/testing the RT patch on *each* of the +10,000 development commits. Sounds like it might work, but no. The +problem here is that the kernel development history is non-linear +in time. See the git FAQ on why bisects can drag you back in time, if +you've never personally encountered this yourself. A lot of people +are surprised by this when they first encounter it. + +My approach was to adopt a semi-brute force approach. During the dev +cycle of any kernel, Linus merges the content from various subsystem +maintainers. Each of these merge points represents a point where +you are guaranteed to not be "rewound in time", should you choose it +as a bisect point. Using git, these points can easily be identified. + +There happens to be ~400 of them, so the 10,000 development commits get +"digested" at an average rate of a humanly manageable number of about 25 +commits each -- something that a stupid person like me has a chance to +be able to diagnose/debug without going insane. You will find that there +is an un-annotated tag for each of these merges in the patch repository. +You really should use these for bisecting your own problems/issues. + +On each of these, I've done a patch test, a compile test (x86, x86-64, +ppc, arm) and a boot test (x86, x86-64, ppc-SMP) to ensure that I've not +done a colossal screw-up. I've probably still screwed *something* up, +but at least I've ensured some level of continuing sanity with these tests +being done across these integration points. |