Subject: [ANNOUNCE] RT for v188.8.131.52 now available.
Date: Friday 4th March 2011 22:24:15 UTC (over 6 years ago)
As a value add to the 2.6.34 long term release, I'm happy to also announce the availability of 2.6.34-RT. You can find it in the v2.6.34-rt branch at: git://git.kernel.org/pub/scm/linux/kernel/git/paulg/rt-patches.git as a repository of patches. The v2.6.34-rt branch contains the latest RT patches against the latest v184.108.40.206 kernel release. (The master branch currently stops at v2.6.34 flat, i.e. 220.127.116.11 so to speak.) I've also created over 400 known working RT enabled bisection points 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. Note that all credit of the thinking and engineering of the RT stuff lies with the original patch authors -- to be clear, I'm just doing the grunt work of a carry forward here. Have fun with it, maybe drop me a note if you find it useful etc. Paul. The carry forward process: --------------------------- 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. For those who track these things, you will know that the most recent release of RT was based on v2.6.33, and in turn, it was created by merging forward the mainline kernel.org v2.6.33 content into the older v2.6.31 RT tree. There was no rebase. With that detail, some of you are probably now going "Aha, now I know why he created that merge-free v2.6.33 based RT tree some weeks ago." (see: http://www.spinics.net/lists/linux-rt-users/msg06310.html ) 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 link for details on the significant work involved with 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. After all, a man has to know his limitations, and I'm pretty much just a patch monkey. 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. -- -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html