git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
The following branches are of interest:
dev
: Bleeding-edge code, both RCU and the
Linux-kernel memory model.
Please do any new RCU development against this branch.
rcu/next
: Outside of the merge window, RCU commits
that have passed a reasonable amount of testing, and have not
yet been proven to be unready for the merge window.
During the merge window, a commit merging the topic branches
which have been accepted in -tip or which will be submitted
directly to mainline during that merge window.
If you want to look at or test newish RCU code, but nevertheless
want something reasonably stable, this is your branch.
kcsan
: Kernel concurrency sanitizer (KCSAN)
updates intended or the next merge window.
Prior to being added to this branch, KCSAN commits often spend
some time in the dev
branch.
lkmm
: Linux-kernel memory model (LKMM) updates intended
for the next merge window.
Note that LKMM patches require at least one Acked-by:
(or Reviewed-by:
) from someone other than the author,
and that Paul E. McKenney's Signed-off-by:
does not count.
lkmm-dev
: Linux-kernel memory model (LKMM) updates
not deemed ready for the next merge window.
Prior to being added to this branch, LKMM commits often spend
some time in the dev
branch.
rcu/urgent
: Fixes for regressions in mainline.
master
: Not intended for any use, but normally set
to a recent rcu/next
for the convenience of anyone
forgetting to check out one of the above branches.
All of the above branches are subject to rebase. However, the old commits are kept around for at least six months by date-stamped branches, for example, “dev.2020.11.05a”.
This tree may be accessed as follows:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git cd linux-rcu git checkout origin/dev
Once created, you can make your local copy incorporate changes as follows:
git remote update git checkout origin/dev
If your development takes some time, please either rebase onto
current origin/dev
before sending your patches.
Regardless of how long your development takes, please test your
code appropriately.
The rcutorture
test suite is easy to run on systems supporting KVM and qemu
,
so please give that a try, especially if your change is at all
non-trivial.
Of course, if you submit too many patches that breaks things, I am likely
to insist that you run rcutorture on subsequent patches.
-rc1
, new commits that are deemed
likely to be ready for the next merge window are collected into
topic branches on top of -rc1
.
New commits that are not likely to be ready are rebased onto
a merge of the topic branches.
The dev
branch includes these not-likely-to-be
ready commits.
dev
branch
any commits that are shown to not be ready for mainline.
-rc1
prove insufficiently stable for
RCU testing, these branches are rebased on top of a later
-rc
.
In happy contrast with the situation prior to -next
and kbuild test robot, -rc1
is usually sufficiently
stable.
-rc
releases from mainline is
performed by first merging dev
with that
-rc
, but leaving the dev
branch
unchanged.
Such merges are sometimes referenced by a test
branch, but these merges are often done within the confines
of the test system.
-rc5
, a pull request is sent
to the -tip
tree.
-tip
tree to mainline during the merge window.
rcutorture
more user-friendly,
enabling distributed rcutorture
runs, and
modifying RCU configuration and diagnostics as needed to
be more compatible with such environments.