1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
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.
|
