Free Software Linux

"I do think 'next' as it is has a few issues that either need to be fixed (unlikely - it's not the point of next) or just need to be aired as issues and understood," noted Linus Torvalds about the linux-next development tree, originally designed as a way to get subsystem maintainers more involved in managing merge conflicts. Linus continued, "I don't think anybody wants it to go away. The question in my mind is more along the way of how/whether it should be changed. There was some bickering about patches that weren't there, and some about how _partial_ series were there but then the finishing touches broke things."

For many years, each Linux kernel release was assigned a series of three numbers, X.Y.Z, with an even Y indicating a "stable" release, and an odd Y indicating an "unstable" development release. Z was incremented for each individual kernel release. The "stable" 1.0.0 Linux kernel was released in March of 1994. New development was then continued in the "unstable" 1.1.z branch, until the "stable" 1.2.0 Linux kernel was release in March of 1995. Major improvements in the kernel lead to X being incremented to 2, and a "stable" 2.0 kernel was released in June of 1996. Active development then continued in the "unstable" 2.1 tree. This process continued with "stable" 2.2, 2.4 and 2.6 kernel trees, and each stable tree gained an official maintainer while Linux creator Linus Torvalds focused on newer features in the next "unstable" tree. Development in these "unstable" trees could go on for periods of multiple years before a "stable" tree was branched.

Years ago, there was a great deal of worry about the possibility of burning out Linus. Life seems to have gotten easier for him since then; now instead, I've heard concerns about burning out Andrew. It seems that you do a lot; how do you keep the pace and how long can we expect you to stay at it?

"This is starting to get beyond frustrating for me," complained David Miller of the latest merge window, launching what turned into a very lengthy and ongoing discussion about the Linux kernel development process. The concept of a regular "merge window" was first discussed in July of 2005 with the release of the 2.6.24-rc4 kernel, following the 2005 Developers' Summit. From 2.6.14 on, the release of each official 2.6.y kernel has been followed by a two week period during which major changes are merged into the kernel, followed by a 2.6.y-rc1 release. David complained that this particular merge window has been more painful than others, "the tree breaks every day, and it's becoming an extremely non-fun environment to work in. We need to slow down the merging, we need to review things more, we need people to test their [...] changes!" During the lengthy discussion, Linux creator Linus Torvalds explained:

Discussing the latest breakage of the linux-next tree, Stephen Rothwell noted that the problem went unnoticed due to the arm tree not currently being included, "this is why I would have liked you to participate in the linux-next tree ...". Arm maintainer Russell King questioned the usefulness, saying, "linux-next will not give me anything which -mm isn't giving me. As I said in the discussion, linux-next value is _very_ small for me. Sorry but true." Several stepped in to offer some reasons that the linux-next tree is useful.

Andrew Morton replied to a commit message making 4k stacks the default, saying, "this patch will cause kernels to crash." Ingo Molnar replied, "what mainline kernels crash and how will they crash? Fedora and other distros have had 4K stacks enabled for years." He added, "we've conducted tens of thousands of bootup tests with all sorts of drivers and kernel options enabled and have yet to see a single crash due to 4K stacks." During the lengthy discussion it was suggested that nfs+xfs+raid kernel configurations, and using ndiswrapper are the most common reasons for overflowing a 4K stack size.

A thread on the Linux Kernel mailing list discussed the process in place for reporting, bisecting and fixing bugs. In response to a suggestion that some of the issues could be solved by introducing new procedures, Al Viro retorted, "we've got ourselves a developing beaurocracy. As in 'more and more ways of generating activity without doing anything even remotely useful'. Complete with tendency to operate in the ways that make sense only to bureaucracy in question and an ever-growing set of bylaws..." Later in the thread, David Miller agreed and noted that ,"the resulting 'bureaucracy' or whatever you want to call it is perceived to undercut the very thing that makes the Linux kernel fun to work on. It's still largely free form, loose, and flexible. And that's a notable accomplishment considering how much things have changed. That feeling is why I got involved in the first place, and I know it's what gets other new people in and addicted too."

"Now that we are (presumably) approaching the next merge window, can I ask what use (if any) will you be making of the linux-next tree? Alternatively, is there any information you want from it?" Stephen Rothwell asked regarding the tree he started maintaining last month for tracking upcoming stable merges. Andrew Morton replied, "afacit it's already working. The level of merge and build errors in the subsystem trees this time around is a tiny fraction of what it was at the same stage in 2.6.24-rcX." He went on to note, "there are 60 or 80 "susbsytem" trees hosted in -mm at present," adding: "I need to find a way to a) get matureish parts of those trees into linux-next and to b) base the rest of -mm off linux-next. I haven't started thinking about that yet. There seem to be some trees which aren't yet in linux-next, some of them significant." read more

"Andrew [Morton] was looking for someone to run a linux-next tree that just contained the subsystem git and quilt trees for 2.6.x+1 and I (in a moment of madness) volunteered. So, this is to announce the creating of such a tree," began Stephen Rothwell, resulting in a lengthy thread discussing the current Linux kernel development process. In a follow up email announcing the first linux-next release, Stephen went on to explain, "it has two branches - master and stable. Stable is currently just Linus' tree and will never rebase. Master will rebase on an almost daily basis (maybe slower at the start)." He then detailed the master branch:

"This is the listing of the open bugs that are relatively new, around 2.6.22 and up. They are vaguely classified by specific area," Natalie Protasevich said, posting a current list of bugs each linking to an appropriate bugzilla.kernel.org entry. Andrew Morton reviewed the list, noting "no response from developers" in response to many of the bugs.

"I'm pleased to announce [the] 7'th and final release of the distributed storage subsystem (DST)," Evgeniy Polyakov stated, completing the TODO list on the project's web page. He titled the release, "squizzed black-out of the dancing back-aching hippo", noting, "it clearly shows my condition". New features in this release include checksum support, extended auto-configuration for detecting and auto-enabling checksums if supported by the remote host, new sysfs files for marking a given node as clean (in-sync) or dirty (not-in-sync), and numerous bug fixes.

A recent report on the lkml suggested improved IO/writeback performance in the recently released 2.6.24-rc1 kernel compared to the earlier 2.6.19.2 and 2.6.22.6 kernels. Credit was given to some patches by Peter Zijlstra. Ingo Molnar replied, "wow, really nice results! Peter does know how to make stuff fast :) Now lets pick up some of Peter's other, previously discarded patches as well :-)" He pointed to several patches "as a starter", then quipped, "I think the MM should get out of deep-feature-freeze mode - there's tons of room to improve :-/"

"The Manageability Engine Interface (aka HECI) allows applications to communicate with the Intel(R) Manageability Engine (ME) firmware. It is meant to be used by user-space manageability applications to access ME features such as Intel(R) Active Management Technology, Intel(R) Quiet System Technology and ASF," Anas Nashif began, describing a new driver for accessing services found in most recent Intel desktop chipsets. Andrew Morton offered an initial review of the patch and asked for additional information, "why do we want to include this code in Linux? What value has it to our users, etc? Basically: tell us more stuff.". Anas added: