Josh Triplett announced the release of Sparse v0.04. Originally written by Linux creator Linus Torvalds, Sparse has been maintained by Josh since 2006. Highlights of the new release include a new automated test suite invoked via 'make check', a new utility named 'c2xml' for generating an XML representation of C files, man pages for 'sparse' and 'cgcc', improved graphing, and numerous bug fixes. The project's web page explains:

"Sparse, the semantic parser, provides a compiler frontend capable of parsing most of ANSI C as well as many GCC extensions, and a collection of sample compiler backends, including a static analyzer also called 'sparse'. Sparse provides a set of annotations designed to convey semantic information about types, such as what address space pointers point to, or what locks a function acquires or releases."

As the Atheros driver issue continues to simmer on the OpenBSD -misc mailing list and the Linux Kernel mailing list, with debate continuing over when the license of source code can be altered or added to, Eben Moglen made a statement for the Software Freedom Law Center. He began by defending their own actions, "it might be useful to recall the first stage of this process, when OpenBSD developers were accused of misappropriating Atheros code, and SFLC investigated and proved that no such misappropriation had occurred? Wild accusations about our motives are even more silly than they are false." He went on to acknowledge, "we understand that attribution issues are critically important to free software developers; we are accustomed to the strong feelings that are involved in such situations. In the fifteen years I have spent giving free legal help to developers throughout the community, attribution disputes have been, always, the most emotionally charged." He added that the SFLC would be making no further statements until their work on this matter was complete, noting:

"Also, and again for the last time, let me state that SFLC's instructions from its clients are to establish all the facts concerning the development of the current relevant code (which means the painstaking reconstruction of several independent and overlapping lines of development, including forensic reconstruction through line-by-line code reviews where version control system information is not available), as well as to resolve all outstanding legal issues, and to make policy recommendations, if possible, that would result in all projects, under both GPL and ISC, having full access to all code on their preferred terms, on an *ongoing* basis, with full respect for everyone's legal rights. We continue to believe those policy goals are achievable in this situation. The required work has been made more arduous because some people have chosen not to cooperate in good faith. But we will complete the work as soon as we can, and we will, as Mr Garvik says, follow the community's practice of complete publication, so everyone can see all the evidence."

Randy Dunlap sent a patch to the Linux kernel mailing list described as adding "info about various email clients and their applicability in being used to send Linux kernel patches." The first revision generated quite a bit of discussion, quickly resulting in a second version, and eventually a third version that Andrew Morton referred to as "soon to be merged". In addition to some general suggestions about emailing patches, it also offers some specific configuration suggestions for a number of popular email clients. It begins:

"Patches for the Linux kernel are submitted via email, preferably as inline text in the body of the email. Some maintainers accept attachments, but then the attachments should have content-type 'text/plain'. However, attachments are generally frowned upon because it makes quoting portions of the patch more difficult in the patch review process.

"Email clients that are used for Linux kernel patches should send the patch text untouched. For example, they should not modify or delete tabs or spaces, even at the beginning or end of lines."

"Looking at these graphs (and the fixed one from your second email), it sure looks a lot like CFS is doing at *least* as well as the old scheduler in every single test, and doing much better in most of them (in addition it's much more consistent between runs)," Kyle Moffett noted regarding recent benchmarks run against the Completely Fair Scheduler by Rob Hussey. Kyle continued:

"This seems to jive with all the other benchmarks and overall empirical testing that everyone has been doing. Overall I have to say a job well done for Ingo, Peter, Con, and all the other major contributors to this impressive endeavor."

"In the patch you really remove _a_lot_ of stuff," commented Roman Zippel in his reaction to Ingo Molnar's latest updates to the Completely Fair Scheduler. Roman has been consistently critical of Ingo's efforts, asking questions and criticizing Ingo's feedback. He continued, "you also removed a lot of things I tried to get you to explain them to me. On the one hand I could be happy that these things are gone, as they were the major road block to splitting up my own patch. On the other hand it still leaves me somewhat unsatisfied, as I still don't know what that stuff was good for."

Ingo replied to Roman's technical concerns, and pointed out that he'd been traveling for the recent kernel summit, adding, "I bent backwards trying to somehow get you to cooperate with us (and I still haven't given up on that!) - instead of you disparaging CFS and me frequently :-(". Willy Tarreau took a more critical stance, calling into question Roman's motives. He noted that he had been impressed by Roman's original review of the scheduler, but disappointed as the discussion seemed to degenerate, "it's the way you're trying to prove Ingo is a bastard and that you're a victim. But if we just re-read a few pick-ups of your mails since Aug 1st, its getting pretty obvious that you completely made up this situation." Kyle Moffett added, "I get the impression that Ingo re-implemented some ideas that you had because you refused to do so in a way that was acceptable for the upstream kernel. How exactly is this a bad thing?"

"It turns out that USB devices suck when it comes to powermanagement issues :(" lamented Greg KH in posting some patches to handle USB autosuspend problems. He noted that the patches were intended for inclusion in the upcoming 2.6.23 kernel, "a number of patches have been submitted near the end of this kernel release cycle that add new device ids to the quirk table in the kernel to disable autosuspend for specific devices. However, a number of developers are very worried that even with the testing that has been done, once 2.6.23 is released, we are going to get a whole raft of angry users when their devices break in nasty ways." He proved an example, "it seems that almost 2/3 of all USB printers just can not handle autosuspend. And there's a _lot_ of USB printers out there..."

Later in the discussion, Linux creator Linus Torvalds commented, "in general, I think the USB blacklist/whitelists are generally a sign of some deeper bug." He continued on to point out a number of quirks in the USB layer that need to be addressed and added:

"We used to have a lot of those things due to simply incorrect SCSI probing, causing devices to lock up because Linux probed them with bad or unexpected modepages etc. I suspect we still have old blacklist entries from those days that just never got cleaned up, because nobody ever dared remove the blacklist entry.

"We should strive to make the default behaviour be so safe that we never need a black-list (or a whitelist), and basically consider blacklists to be not a way to 'fix up a device', but a way to avoid some really serious AND *RARE* error."

"With 2.6.24 probably opening in the not-too-distant future, it's probably a good time to review what my plans are for when the merge window opens," began Roland Dreier on the Linux Kernel mailing list. He reflected on the recent decision to phase in usage of reviewed-by tags noting that he was a little behind on reviews, "unfortunately, due to the length of the backlog and the fact that 2.6.23 seems fairly close, some of the things listed below are going to miss the 2.6.24 merge window." Roland continued, stressing the importance of getting in-depth reviews:

"Although the plan is to phase in requiring 'Reviewed-by:' gently, for this merge, if you can get someone other than me to review your work, then the chances of it being merged increase dramatically. I'm talking about a real review -- ideally, someone independent (from another company would be good) who is willing to provide a 'Reviewed-by:' line that means the reviewer has really looked at and thought about the patch. There should be a mailing list thread you can point me at where the reviewer comments on the patch and a new version of that patch addressing all comments is posted (or in exceptional cases, where the patch is perfect to start with, where the reviewer says the patch is great)."

"This version has a lot of corrections, and is stable at least on my machine," noted Linus Torvalds in the 0.11 Linux kernel release announcment, "I /hope/ every known bug is fixed, but no promises (and all unknown bugs are still there, probably with reinforcements ;-)". The 0.11 kernel was released on December 8th, 1991, gaining demand loading, the mkfs, fsck and fdisk utilities, improved floppy drivers, a console that could generate beeps, support for US, German, French and Finnish keyboards, and settable line-speeds for the com ports (instead of having them hard-coded to 2400bps). Noticeably lacking was support for SCSI, an init/login system (Linux 0.11 booted into a root bash prompt), and paging to disk:

"Although I have a somewhat working VM (paging to disk), it's not ready yet. Thus linux needs at least 4M to be able to run the GNU binaries (especially gcc). It boots up in 2M, but you cannot compile."

"An ongoing study on datasets of several Petabytes have shown that there can be 'silent data corruption' at rates much larger than one might naively expect from the expected error rates in RAID arrays and the expected probability of single bit uncorrected errors in hard disks," began a recent query on the Linux kernel mailing list asking where the errors might be introduced. Alan Cox replied, "its almost entirely device specific at every level." He then continued on with some general information, tracing the path of the data from the drive, through the cable and bus, into main memory and the CPU cache, as well as over the network, "once its crossing the PCI bus and main memory and CPU cache its entirely down to the system you are running what is protected and how much. Note that a lot of systems won't report ECC errors unless you ask." Alan continued:

"The next usual mess is network transfers. The TCP checksum strength is questionable for such workloads but the ethernet one is pretty good. Unfortunately lots of high performance people use checksum offload which removes much of the end to end protection and leads to problems with iffy cards and the like. This is well studied and known to be very problematic but in the market speed sells not correctness."

Regarding the specific study in question, Alan noted, "for drivers/ide there are *lots* of problems with error handling so that might be implicated (would want to do old [versus] new ide tests on the same h/w which would be very intriguing)."

"The aim of these four patches is to introduce Virtual Machine time accounting," began Laurent Vivier. He described the first two patches as:

"1) As recent CPUs introduce a third running state, after 'user' and 'system', we need a new field, 'guest', in cpustat to store the time used by the CPU to run virtual CPU. Modify /proc/stat to display this new field.

"2) Like for cpustat, introduce the 'gtime' (guest time of the task) and 'cgtime' (guest time of the task children) fields for the tasks. Modify signal_struct and task_struct. Modify /proc/<pid>/stat to display these new fields."

Both Ingo Molnar and Rik van Riel responded favorably to the patch. Ingo replied, "the concept certainly looks sane to me," adding, "I'd suggest inclusion into 2.6.24." Regarding concerns that the new information at the end of the line could break utilities such as top or ps, Rik assured that it would not, "we have added numbers to the cpu lines in /proc/stat since early 2.6. All the programs parsing /proc/stat should just scan for a number of numbers from the start of the line, without trying to scan for the terminating newline."

Having recently returned from the Linux kernel summit, Ingo Molnar and Peter Zijlstra sent out some performance updates to the Completely Fair Scheduler:

"Our main focus has been on simplifications and performance - and as part of that we've also picked up some ideas from Roman Zippel's 'Really Fair Scheduler' patch as well and integrated them into CFS. We'd like to ask people go give these patches a good workout, especially with an eye on any interactivity regressions."

He noted that some of the changes included removing features that had proved unecessary. "while keeping the things that worked out fine, like sleeper fairness." Ingo posted some results from the lmbench benchmark noting around a 16% speedup on both the 32-bit and 64-bit x86 architectures. He added, "we are now a bit faster than the O(1) scheduler was under v2.6.22 - even on 32-bit. The main speedup comes from the avoidance of divisions (or shifts) in the wakeup and context-switch fastpaths."

Nigel Kukard posted an announcement for an early version of "BootUtils". The utilities currently support the ext2, ext3, jfs, reiserfs and xfs filesystems. He explained:

"BootUtils is a collection of utilities to facilitate booting of modern Kernel 2.6 based systems. BootUtils is designed for initramfs, although volunteers to add support for initrd are welcome. The process of finding the root volume either by label or explicit label= on the kernel command line, mounting it and 'switchroot'ing is automated. BootUtils can also drop to emergency shell if the root volume cannot be mounted. Why not even start sshd and allow admin login if the box is in a remote location?"

Linus Torvalds announced the sixth release candidate of the upcoming 2.6.23 kernel, a final release expected within the next few weeks. He noted:

"So last week was a bust, with a lot of core people away for the kernel summit, and with -rc5 having two rather nasty (and silly) one-liner problems that bit a number of people - a missing NULL pointer check in TCP, and a missing list terminator in ata_piix.

"So the fixes for those things were both pretty trivial, and they've been in the -git trees for the last few days, but I just pushed out an -rc6 that also merges up some other updates that did come in during the week."

The -rc6 source level changes can be browsed via the gitweb interface.

"The cfs core has been enhanced since quite sometime now to understand task-groups and [to] provide fairness to such task-groups," began Srivatsa Vaddagiri, "what was needed was an interface for the administrator to define task-groups and specify group 'importance' in terms of its cpu share. The patch below adds such an interface."

Srivatsa requested that his patch be merged into Andrew Morton's -mm tree to receive more testing, "note that the load balancer needs more work, esp to deal with cases like 2-groups on 4-cpus, one group has 3 tasks and other having 4 tasks. We are working on some ideas, but nothing to share in the form of a patch yet. I felt sending this patch out would help folks start testing the feature and also improve it."

"The objective of this patchset is to keep the system in a state where actions such as page reclaim or memory compaction will reduce external fragmentation in the system," Mel Gorman described his set of thirteen patches labeled "reduce external fragmentation by grouping pages by mobility v30". He explained, "it works by grouping pages of similar mobility together in PAGEBLOCK_NR_PAGES areas." He defined four mobility types as: "UNMOVABLE - Pages that cannot be trivially reclaimed or moved; MOVABLE - Pages that can be moved using the page migration mechanism; RECLAIMABLE - Pages that the kernel can often directly reclaim such as those used for inode caches; RESERVE - The areas where min_free_kbyte-related pages should be stored". Mel added:

"This grouping clearly requires additional work in the page allocator. kernbench shows effectively no performance difference varying between -0.2% and +1% on a variety of test machines. Success rates for huge page allocation are dramatically increased. For example, on a ppc64 machine, the vanilla kernel was only able to allocate 1% of memory as a hugepage and this was due to a single hugepage reserved as min_free_kbytes. With these patches applied, 40% was allocatable as superpages."