"It hasn't been a week, I know, and this is a pretty small set of changes since -rc7, but I'm going to be mostly incommunicado for the next week or so, so I just released what will hopefully be the last -rc," began Linux creator Linus Torvalds, announcing the 2.6.26-rc8 kernel. He added, "or maybe not. It depends on how good you all are while I'm not looking." Regarding the latest release candidate, Linus explained:

"Most of the bulk of the changes here are to Xen and to KVM in particular, which shows up as a rather unusual dirstat: 65% is in arch/x86 (counting the asm-x86 changes too). The rest is mostly random stuff, the appended ShortLog gives a reasonable idea. Several bugzilla entries are hopefully now closed."

"Another week, another -rc," began Linux creator Linus Torvalds, announcing the 2.6.26-rc7 Linux kernel, "and as usual, it's mainly drivers and arch updates - over 90% of changes are in one or the other." He continued:

"A big part of it (about two thirds of the driver update, in fact) is a late-dropping AGP/DRM update that adds support for some new Intel and ATI graphics cards. And a big part of the arch update is the inevitable def_config updates, of course. I'm not all that happy about the timing of the support for the new cards, but at the same time I also hate delaying new drivers. Obviously the hope is that it can't cause any regressions, since the added code is almost entirely for stuff that simply wasn't supported at all before."

Linus concluded, "if you ignore the driver and arch updates, the rest is pretty minor. About half is in networking, and half of the remaining is filesystems updates (mainly ocfs2). And random smatterings elsewhere, like some scheduler updates."

"In the kerneloops.org stats, a new oops is rapidly climbing the charts, began Arjan van de Ven, referring to his website where he automatically collects kernel oops and warning reports from mailing lists, bugzillas, and a special client. Regarding the latest oops, he noted, "the oops is a page fault in the ext3 'do_slit' function, and the first report of it was with 2.6.26-rc6-git3." Linux creator Linus Torvalds took a quick interest in the issue, observing that all the oopses seemed to be on the i686 architecture, suggesting, "could this perhaps be an indication that it is specific to i686 some way (eg a compiler issue?)"

Shortly before Linus sent out his emails, Dave Airlie confirmed that this was indeed a known compiler bug affecting GCC 4.3.1. The bug report notes, "any ext* filesystem which enables the dir_index feature is likely susceptible". Linus caught up on his email and retorted, "gaah. I should read all my email instead of wasting my time trying to match up the code with what I can reproduce.." The reason the Red Hat bug report wasn't automatically picked up by the kerneloops website was because the oops was reported in a jpeg image, leading Arjan to quip, "maybe one day if I'm really bored I'll implement OCR into [kerneloops.org] ;)".

"I'd like to say that the diffs are shrinking and things are calming down, but I'd be lying," began Linux creator Linus Torvalds, announcing the 2.6.26-rc6 kernel. He noted, "another week, another -rc, and another 350 commits. Yes, the diff is smaller than the one from rc4 to rc5 (despite having more commits), so we're on the right trajectory, but I was hoping for less churn at this stage." Linus continued:

"As usual, most of the changes are to drivers (with arch updates a strong second). The DVB updates are the biggest chunk of that, but on the whole it's quite spread out. As mentioned, the diffs are smaller and there are more commits, and yes, most of the commits are really rather small and trivial fixes.

"Give it a try, we should have a few less regressions once more,"

"Another week, another batch of mostly pretty small fixes. Hopefully the regression list is shrinking, and we've fixed at least a couple of the oopses on Arjan's list," said Linux creator Linus Torvalds, announcing the 2.6.26-rc5 kernel. He added, "as usual, the bulk of the changes are in drivers and arch code - together they are about 70% of the diffstat. And the arch stats are bloated by some new/updated SH and avr defconfig files, which is also fairly common at this stage." Linus concluded:

"Perhaps unusually, 13% is in kernel/, almost all of it fixing up some scheduler issues - with the bulk of it by far being a couple of reverts due to performance regressions. But there's a few other fixes too. And then there is networking and some ocfs2 updates. Along with various one-liners sprinkled all around.

"The shortlog (appended) gives a reasonable view of it all. Nothing hugely exciting sticks to my mind, but then I don't think we've had any really hugely exciting problem spots either.."

"You know the drill by now: another week, another -rc," began Linux creator, Linus Torvalds, announcing the 2.6.26-rc4 kernel. "There's a lot of small stuff in here", he continued, "most people won't even notice. The most noticeable thing is for all you 32-bit x86 people who use PAE (enabled by the HIGHMEM64G config option) due to having too much memory in your machine - mprotect() was broken due to some of the PAT fix/cleanup patches, causing the NX bit to be not set correctly." Linus described the fixed bug:

"If you had PAE enabled _and_ a recent enough CPU to have NX, but not recent enough to be 64-bit (or you were just perverse and wanted to run a 32-bit kernel despite having a chip that could do 64-bit and enough memory that you _really_ should have used a 64-bit kernel), you'd get various random program failures with SIGSEGV. It ranged from X not starting up to apparently OpenOffice not working if it did."

He went on to note, "most of the changes, as usual, are in drivers, at 60%, with some DRI changes leading the way (fixing a number of other regressions, mainly by reverting the under-cooked vblank update). Network, MMC, USB, watchdog and IDE drivers also got updates. We had CIFS and NFS updates, and some arch updates as usual." Linus concluded, "nothing really hugely exciting, I think we're doing pretty ok in the release cycle, and I'm getting the feeling that things are calming down."

"Is there a write up of what you consider the 'proper' git workflow?" Theodore Ts'o asked Linux creator Linus Torvalds, "why do you consider rebasing topic branches a bad thing?" Linus replied, "rebasing branches is absolutely not a bad thing for individual developers. But it *is* a bad thing for a subsystem maintainer." He went on to differentiate between 'grunts' who write the code and 'managers' who primarily collect other people's code, "a grunt should use 'git rebase' to keep his own work in line. A technical manager, while he hopefully does some useful work on his own, should strive to make _others_ do as much work as possible, and then 'git rebase' is the wrong thing, because it will always make it harder for the people around you to track your tree and to help you update your tree." Linus compared his own patch management style and productivity from over six years ago before he started using BK and git, to his current style using git:

"You can either try to drink from the firehose and inevitably be bitched about because you're holding something up or not giving something the attention it deserves, or you can try to make sure that you can let others help you. And you'd better select the 'let other people help you', because otherwise you _will_ burn out. It's not a matter of 'if', but of 'when'. [...] And when you're in that kind of ballpark, you should at least think of yourself as being where I was six+ years ago before BK. You should really seriously try to make sure that you are *not* the single point of failure, and you should plan on doing git merges. [...] I think a lot of people are a lot happier with how I can take their work these days than they were six+ years ago."

"This time around, we have 60+% of the changes in drivers, notably drives/video and drivers/media, with some infiniband, networking and usb lovin' to fill things out," began Linux creator Linus Torvalds, announcing the 2.6.26-rc3 kernel. "The rest is (as usual) mostly arch updates," he continued, "this time mostly mips, m68k and uml." Linus noticed that Linux kernel development has been managed with git now as long as it was managed with BitKeeper, a little over three years for both tools. He explained, "the most striking difference has nothing to do with git or BK (the switch-over timing was just the reason I decided to take a look), but with the fact that we're not just continuing to develop, but we're developing faster and with more people," adding:

"So during the three years 2002->2005, we had 63,428 commits, attributed to 1,560 different authors (caveat: misspellings etc will mean that some people get counted more than once). During the last three years, we've had 96,885 attributed to 4,068 distinct authors (with the same caveat, obviously).

"I didn't do a lot of per-commit statistics yet, but from the little I've done it also seems like we've gotten increasingly better at doing small commits (which is probably one of the reasons we have a larger number of them, but also why we have more authors - small commits is how people get into doing kernel development)."

"As some of the latency junkies on lkml already know, commit 8e3e076 in v2.6.26-rc2 removed the preemptible BKL feature and made the Big Kernel Lock a spinlock and thus turned it into non-preemptible code again. This commit returned the BKL code to the 2.6.7 state of affairs in essence," began Ingo Molnar. He noted that this had a very negative effect on the real time kernel efforts, adding that Linux creator Linus Torvalds indicated the only acceptable way forward was to completely remove the BKL. Ingo explained:

"This task is not easy at all. 12 years after Linux has been converted to an SMP OS we still have 1300+ legacy BKL using sites. There are 400+ lock_kernel() critical sections and 800+ ioctls. They are spread out across rather difficult areas of often legacy code that few people understand and few people dare to touch. It takes top people like Alan Cox to map the semantics and to remove BKL code, and even for Alan (who is doing this for the TTY code) it is a long and difficult task."

Ingo went on to describe how the BKL works, how it differs from other locking mechanisms, and why this complicates removing it permanently from the kernel. He noted that the various dependencies of the lock are lost in the haze of 15 years of code changes, "all this has built up to a kind of Fear, Uncertainty and Doubt about the BKL: nobody really knows it, nobody really dares to touch it and code can break silently and subtly if BKL locking is wrong." He then suggested "changing the rules of the game", creating a "kill-the-BKL" branch which "turns the BKL into an ordinary albeit somewhat big mutex, with a quirky lock/unlock interface called 'lock_kernel()' and 'unlock_kernel()'."

"About 45% architecture updates (counting the include files too), about 30% drivers, and about 25% odds-and-ends. The odds-and-ends are mainly Documentation, filesystems (mostly cifs) and core kernel (scheduler updates etc)," said Linux creator Linus Torvalds, announcing the 2.6.26-rc2 kernel. He added, "if you read the shortlog and get the feeling that most of it is pretty boring small details, you'd be right. There is little exciting there." He continued:

"A fairly small part of it, but quite possibly the most noticeable one, is how the semaphore changes impacted the BKL (the old 'big kernel lock' that is still used for some legacy code, for you non-core people out there), which in the past had different versions ('regular', 'preemptable'). A few months ago we dropped the regular BKL version, but in 2.6.25-rc1 we then had performance (and then correctness) issues with the interaction between the semaphore implementation and the preemptable BKL, so we're back to the old regular version for now."