It was recently pointed out that most of the x86 architecture patches had been merged into the mainline 2.6.25 kernel, except for the kgdb patches. Linus Torvalds replied, "I won't even consider pulling it unless it's offered as a separate tree, not mixed up with other things. At that point I can give a look." He continued:

"That said, I explained to Ingo why I'm not particularly interested in it. I don't think that 'developer-centric' debugging is really even remotely our problem, and that I'm personally a lot more interested in infrastructure that helps normal users give better bug-reports. And kgdb isn't even _remotely_ it.

"So I'd merge a patch that puts oops information (or the whole console printout) in the Intel management stuff in a heartbeat. That code is likely much grottier than any kgdb thing will ever be (Intel really screwed up the interface and made it some insane XML thing), but it's also fundamentally more important - if it means that normal users can give oops reports after they happened in X (or, these days, probably more commonly during suspend/resume) and the machine just died."

Joseph Myers announced the availability of GCC 4.2.3 saying, "GCC 4.2.3 is a bug-fix release, containing fixes for regressions in GCC 4.2.2 relative to previous GCC releases." He adds, "as always, a vast number of people contributed to this GCC release -- far too many to thank individually!"

GCC is the GNU Compiler Collection which includes C, C++, Objective-C, Fortran, Java, and Ada compilers. Download GCC 4.2.3 from your nearest gcc.gnu.org mirror.

"I re-ran some statistics the other day on our kernel development rate, and changed my formula after Andrew accused me of severely undercounting the rate of change," noted Greg KH during a discussion about the stability of the Linux kernel while undergoing significant changes. He continued, "turns out that as of 2.6.24-rc8 for the 2.6.24 kernel release we did: lines added per day, 4945; lines removed per day, 2006; lines modified per day, 1702". Greg added:

"And note, that is real stuff, not renames or file moves at all, git handles not reporting that. That's for the 99 days that it took to do 2.6.24-rc8 (I need to re-run the scripts now that 2.6.24 is out.) It's fricken scarily amazing that things are still working at all... Just something to make you all sleep well at night :)"

"The latest feature release GIT 1.5.4 is available at the usual places," began Git maintainer Junio Hamano. He continued, "it has been an unusually long cycle. 5 months since the last feature release 1.5.3 was really a bit too long. But I hope it was worth waiting for. Thanks everybody for working hard to improve it." He noted that there were 165 contributers resulting in 684 changed files, included 70,435 insertions and 28,984 deletions.

The Git distributed version control system was originally written by Linus Torvalds in April of 2005 to temporarily replace BitKeeper, which he had been using to manage kernel source code since February of 2002. Junio Hamano took over maintainership of Git a few months later, in July of 2005, and the tool has long since become quite popular outside of even Linux kernel development. Regarding the latest stable release, Junio highlighted some of the changes, including:

"Comes with much improved gitk, with i18n; comes with git-gui 0.9.2 with i18n; progress displays from many commands are a lot nicer to the eye; rename detection of diff family while detecting exact matches has been greatly optimized; 'git diff' sometimes did not quote paths with funny characters properly; various Perforce importer updates; 'git clean' has been rewritten in C; 'git push' learned --dry-run option to show what would happen if a push is run; 'cvs' is recognized as a synonym for 'git cvsserver', so that CVS users can be switched to git just by changing their login shell; 'git add -i' UI has been colorized; 'git commit' has been rewritten in C; 'git bisect' learned 'skip' action to mark untestable commits; 'git svn' wasted way too much disk to record revision mappings between svn and git, a new representation that is much more compact for this information has been introduced to correct this; in addition there are quite a few internal clean-ups."

Ingo Molnar summarized his pull request for changes to the x86 architecture bound for mainline inclusion in 2.6.25 noting, "it's not a small merge, it consists of 908 commits from 96 individual arch/x86 developers (!)". He continued, "a number of core files are changed as well: most notably percpu, debugging details, timers, the firewire remote debugging patch and ... the KGDB remote debugging stub in kernel/kgdb.c." He went on to detail the extent of the testing this tree has received, "in the past few weeks tens of thousands of random x86.git bzImages were successfully built and booted on a number of (commodity) 32-bit and
64-bit testsystems - and there has been a fair amount of test exposure on -mm as well." Regarding the remote kernel debugger, Ingo explained:

"We tested KGDB to be merge-worthy within the x86 architecture (the only supported architecture for now) and it's better to have kernel/kgdb.c than arch/x86/kernel/kgdb.c. The code is reasonably clean and the user-space exposure is small - the only real exposure is the decades-old remote GDB protocol. We are happy to fix up any further cleanliness comments that people might have - but we really wanted to start somewhere and get this thing moving. As an added bonus: finally a kernel debugger that can be read without puking too much ;-) [anyone remember KDB?]"

Avi Kivity summarized the kvm patches bound for the 2.6.25 kernel:

"Changes include performance and scalability improvements, completion of the portability work (though no new architectures are supported with this submission), support for new hardware features, using general userspace memory for kvm (which enables swapping guest memory as well as sharing memory among guests), as well as the usual cleanups and incremental fixes."

The Kernel-based Virtual Machine project, kvm, was started in mid-2006, and has been part of the Linux kernel since the 2.6.20 release in February of 2007. The recent changes can be browsed with gitweb.

"As you probably know there is a trend in enterprise computing towards networked storage. This is illustrated by the emergence during the past few years of standards like SRP (SCSI RDMA Protocol), iSCSI (Internet SCSI) and iSER (iSCSI Extensions for RDMA)," began Bart Van Assche, proposing that SCST be merged into the mainline kernel. He suggested that while similar to the STGT project which has been part of the mainline kernel since 2.6.20, "SCST is superior to STGT with respect to features, performance, maturity, stability, and number of existing target drivers. Unfortunately the SCST kernel code lives outside the kernel tree, which makes SCST harder to use than STGT."

SCSI subsystem maintainer, James Bottomley, was not convinced, explaining:

"The two target architectures perform essentially identical functions, so there's only really room for one in the kernel. Right at the moment, it's STGT. Problems in STGT come from the user<->kernel boundary which can be mitigated in a variety of ways. The fact that the figures are pretty much comparable on non IB networks shows this. I really need a whole lot more evidence than at worst a 20% performance difference on IB to pull one implementation out and replace it with another. Particularly as there's no real evidence that STGT can't be tweaked to recover the 20% even on IB."